I have a few questions regarding the Tangram ORM.
Can some Tangram guru advise what does it mean that Tangram has no support for SQL UPDATE?
Also, is this ORM in general a good choice and in what cases?
Well, it does support SQL UPDATE. Solving another problem (partial column select -- I hardly understand what it means) might result in such inability. That's how I've read the doc you linked to.
My experience with Tangram is very limited, though.
Related
Anyone familiar enough with the Cassandra engine (via PHP using phpcassa lib) to know offhand whether there's a corollary to the sql-injection attack vector? If so, has anyone taken a stab at establishing best practices to thwart them? If not, would anyone like to ; )
No. The Thrift layer used by phpcassa is an rpc framework, not based on string parsing.
An update - Cassandra v0.8 introduced CQL, which might have brought with it the possibility of injection attacks. However:
Prepared statements were then introduced in Cassandra v1.1.0, which help to prevent such attacks.
Furthermore, see this posting which explains features of CQL that make it resistant to injection, including:
each CQL query must contain exactly one statement
as a rule of thumb, there are also no statement types that contain
other statements, which would be another common vector for an
injection.
What is the best non-ORM database to work with Scala? I find this link link text, but this does not answer my question fully.
Could be considered desirable features performance, scalability and facility to write complex structures of relationships between data.
Thanks
Do you mean non-relational? There are Scala client libraries/wrappers for many NoSQL databases, including Cassandra, MongoDB, Redis, Voldemort, CouchDB, etc.
If by "complex structures of relationships between data" you mean that you'd prefer not to have to normalize, any NoSQL database should do reasonably well.
However, note that none of them--to my knowledge--will do anything like enforcing a referential integrity constraint or dereferencing object navigation paths for you. For that you may want to consider a graph database or OODBMS; unfortunately I'm not aware of any that's open source, liberally licensed and clusterable.
Update: I just found OrientDB which actually meets all threetwo of these criteria.
Update 2: OrientDB's clustering support isn't released yet. As a wise man once said, two out of three ain't bad.
The best solution is probably not to worry about it...
Abstract away from the problem by using the pluggable-persistence support in Akka: http://doc.akkasource.org/persistence
Then you can try them all, and take your pick based on profiling results :)
There was an article on Hacker News a couple of days ago that reached first page titled something like
"2 cases when not to use Mongodb" but I really can't find it anymore...
Does anyone know where I can find the above described article?
What cases are there when NoSQL fails?
We use MongoDB for storing tons and tons of analytics data for which we don't care if some stuff occasionally gets lost in a server crash. The data really fits MongoDB well and it would have been a nightmare if we were to use an SQL database for this. But for bank transactions we wouldn't even consider MongoDB.
The write lock might be a problem for some people. On the other hand MongoDB supports easy sharding, much easier than with SQL. Sharding allows us to scale horizontally which is a huge plus for our data.
http://news.ycombinator.com/item?id=1691748
By any reasonable definition "NoSQL" ought to include non-SQL RDBMSs in its scope (because there's no sound reason why the relational model can't address the same requirements as other NoSQL models). If you accept that, then there is no limit to what NoSQL DBMSs could do. We would have no more need of SQL - ever!
Sadly, there seems to be a common assumption among NoSQL thought leaders that "NoSQL" has to mean "not relational". That is highly unfortunate because if the relational model is ignored then NoSQL is never likely to replace SQL for many purposes. (I take it for granted that finding a long-term, relational model replacement for SQL would actually be a good thing :)
You don't want to use NoSQL typically when you....
... don't want to use SQL! /hardy har har
Most of the NoSQL solutions I've seen seem to fall in the key-value store approach, and aren't relational. They tend to give up ACID properties.
So when you evaluate a database system, when you don't need ACID, when you don't want relational algebra, when you do have a need for a KV store, then the NoSQL approach is your friend.
Note too that there is a wide variety of 'NoSQL' systems, and they all are busily working on slightly different approaches.
There appears to be a myriad of NoSQL databases available these days:
CouchDB
MongoDB
Cassandra
Hadoop
There's also a boundary between these tools and tools such as Redis that work as a memcached replacement.
Without hand waving and throwing too many buzz words - my question is the following:
How does one intelligently decide which tool here makes the most sense for their project? Are the projects similar enough to where the answer to this is subjective, eg: Ruby is better than Python or Python is better than Ruby? Or are we talking Apples and oranges here in that they each of them solve different problems?
What's the best way to educate myself on this new trend?
Perhaps one way to think of it is, programming has recently evolved from using one general-purpose language for everything to using the general-purpose language for most things, plus domain-specific languages for the more appropriate parts. For example, you might use Lua to script artificial intelligence of a character in a game.
NoSQL databases might be similar. SQL is the general purpose database with the longest and broadest adoption. While it could be shoehorned to serve many tasks, programmers are beginning to use NoSQL as a domain-specific database when it is more appropriate.
I would argue, that the 4 major players you named do have quite different featuresets and try to solve different problems with different priority.
For instance, as far as i know Cassandra (and i assume Hadoop) central focus is on large scale installations.
MongoDb tries to be a better scaling alternative to classic SQL servers in providing comparably powerful query functions.
CouchDB's focus is comparably small scale (will not shard at all, "only" replicate), high durability and easy synchronization of data.
You might want to check out http://nosql-database.org/ for some more information.
I am facing pretty much the same problem as you, and i would say there is no real alternative to look at all solutions in detail.
Check out this site: http://cattell.net/datastores/ and in particular the PDF linked at the bottom (CACM Paper). The latter contains an excellent discussion of the relative merits of various data store solutions.
It's easy. NoSQL databases are ACID compliant databases minus some guarantees. So just decide which guarantees you can do without and find the database that fits. If you don't need durability for example, maybe redis is best. Or if you don't need multi-record transactions, then perhaps look into mongodb.
I'm an old-school database programmer. And all my life i've working with database via DAL and stored procedures. Now i got a requirement to use Entity Framework.
Could you tell me your expirience and architecture best practicies how to work with it ?
As I know ORM was made for programmers who don't know SQL expression. And this is only benefit of ORM. Am I right ?
I got architecture document and I don't know clearly what I shoud do with ORM. I think that my steps should be:
1) Create complete database
2) Create high-level entities in model such "Price" which is realy consists from few database tables
3) Map database tables on entities.
An ORM does a lot more than just allow non-SQL programmers to talk to databases!
Instead of having to deal with loads of handwritten DAL code, and getting back a row/column representation of your data, an ORM turns each row of a table into a strongly-typed object.
So you end up with e.g. a Customer, and you can access its phone number as a strongly-typed property:
string customerPhone = MyCustomer.PhoneNumber;
That is a lot better than:
string customerPhone = MyCustomerTable.Rows[5].Column["PhoneNumber"].ToString();
You get no support whatsoever from the IDE in making this work - be aware of mistyping the column name! You won't find out 'til runtime - either you get no data back, or you get an exception.... no very pleasant.
It's first of all much easier to use that Customer object you get back, the properties are nicely available, strongly-typed, and discoverable in Intellisense, and so forth.
So besides possibly saving you from having to hand-craft a lot of boring SQL and DAL code, an ORM also brings a lot of benefits in using the data from the database - discoverability in your code editor, type safety and more.
I agree - the thought of an ORM generating SQL statements on the fly, and executing those, can be scary. But at least in Entity Framework v4 (.NET 4), Microsoft has done an admirable job of optimizing the SQL being used. It might not be perfect in 100% of the cases, but in a large percentage of the time, it's a lot better than any SQL any non-expert SQL programmer would write...
Plus: in EF4, if you really want to and see a need to, you can always define and use your own Stored procs for INSERT, UPDATE, DELETE on any entity.
I can relate to your sentiment of wanting to have complete control over your SQL. I have been researching ORM usage myself, and while I can't state a case nearly as well as marc_s has, I thought I might chime in with a couple more points.
I think the point of ORM is to shift the focus away from writing SQL and DAL code, and instead focus more on the business logic. You can be more agile with an ORM tool, because you don't have to refactor your data model or stored procedures every time you change your object model. In fact, ORM essentially give you a layer of abstraction, so you can potentially make changes to your schema without affecting your code, and vice-versa. ORM might not always generate the most efficient SQL, but you may benefit in faster development time. For small projects however, the benefits of ORM might not be worth the extra time spent configuring the ORM.
I know that doesn't answer your questions though.
To your 2nd question, it seems to me that many developers on S.O. here who are very skilled in SQL still advocate the use of and themselves use ORM tools such as Hibernate, LINQ to SQL, and Entity Framework. In fact, you still need to know SQL sometimes even if you use ORM, and it's typically the more complicated queries, so your theory about ORM being mainly "for programmers who don't know SQL" might be wrong. Plus you get caching from your ORM layer.
Furthermore, Jeff Atwood, who is the lead developer of S.O. (this site here), claims that he loves SQL (and I'd bet he's very good at it), and he also strives to avoid adding extra tenchnologies to his stack, but yet he choose to use LINQ to SQL to build S.O. Years ago already he claimed that, "Stored Procedures should be considered database assembly language: for use in only the most performance critical situations."
To your 1st question, here's another article from Jeff Atwood's blog that talks about varies ways (including using ORM) to deal with the object-relational impedance mistmatch problem, which helped me put things in perspective. It's also interesting because his opinion of ORM must have changed since then. In the article he said you should, "either abandon relational databases, or abandon objects," as well as, "I tend to err on the side of the database-as-model camp." But as I said, some of the bullet points helped put things into perspective for me.