tag:blogger.com,1999:blog-35275067.post2007236447950587654..comments2011-07-18T18:05:29.630-05:00Comments on /dev/rohner: The Database RantAllen Rohnerhttp://www.blogger.com/profile/14551766042595741221noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-35275067.post-74905478812151719712009-04-23T14:03:00.000-05:002009-04-23T14:03:00.000-05:00Check our Adam Marcus's BlendDB MIT Masters thesis...Check our Adam Marcus's BlendDB MIT Masters thesis project. It talks about table layout schemes for relational databases that are geared toward navigating records.John Zabroskihttps://www.blogger.com/profile/17294832205855394228noreply@blogger.comtag:blogger.com,1999:blog-35275067.post-38402171117756697622009-04-23T08:04:00.000-05:002009-04-23T08:04:00.000-05:00I would respectfully disagree. I will be happy to...I would respectfully disagree. I will be happy to move away from SQL when something better comes along, but I am not certain that what you are describing is better, and I think some of your assumptions are false. (Though I would love to see select statements become fully comoposable as you described and still maintain performance.) <br /><br />For one thing, you say that ORMs are the dominant model. I am not certain that is true yet since most projects I have worked on and talked to others about do not use them. <br /><br />And you point out that ORMs are a leaky model, which I will agree with, but look at the how young they are relatively. Microsofts main ORM Linq was released at the end of 2007. The other one I have worked with is SQL Alchemy which has not even hit the 1.0 milestone. They have major problems now, but they will get better.<br /><br />And you say that there is no low level access to the data. This is partially true, but for multiuser environments with potentially mixed programming languages I think this may be a good thing and is at worst a mixed blessing. Also keep in mind that many RDBMS's do offer a fairly good degree of control over the plan that will be used. MS SQL Server for instance has a variety of query hints which let you force a lot of the paramaters of the final plan.<br /><br />As someone who regularly uses more than one programming language I would be very concerned about your suggestion to pick a virtual machine. That would strongly suggest a particular language to use with that database as well as end up keeping on many of your complaints about primitive type mismatches when you did use a different language.<br /><br />I see where you are coming from and you have some valid points, but at least for the forseeable future I believe the answer is to continue to refine and evolve SQL and the new ORM systems, not to discard them by the wayside.Unknownhttps://www.blogger.com/profile/10736454535320279984noreply@blogger.comtag:blogger.com,1999:blog-35275067.post-25866421116160697432009-04-23T04:46:00.000-05:002009-04-23T04:46:00.000-05:00Disagree with Andy Chambers, RDF triple store woul...Disagree with Andy Chambers, RDF triple store would be SQL of semantic web :-)<br /><br />Agree SQL should and will die soon. <br /><br />Advanced semantic technologies will replace all this stuff.<br /><br />Eventually all will be in the Global Brain anyway.<br /><br />Pawel Lubczonok<br />ThoughtExpressUnknownhttps://www.blogger.com/profile/01028061132102743302noreply@blogger.comtag:blogger.com,1999:blog-35275067.post-84217870762005318212009-04-22T18:02:00.000-05:002009-04-22T18:02:00.000-05:00This has been done by IBM! It's called RPG. Repo...This has been done by IBM! It's called RPG. Report Program Generator language. It provides a non-sql interface to a dbms on iSeries/AS400 midrange computers. <br /><br />compared to python and SQL it sucks. <br /><br />you started your rant by pointing out that SQL was created for business analysts of a DBMS not programmers. Thus, the easiest solution to ad hoc queries is to expose the SQL interface to those users. <br /><br />Managing users and table/column authorizations in a single application is a reasonably safe way to handle this. Letting a user write their own SQL and not have to bother the developers. <br /><br />For complex and varied queries, I generally embed select statements in the database itself, using variables, to achieve a level of composability. In this way, specific queries can be generated as a function of a higher query with a bit of search and replace. <br /><br />It's also possible to store database definitions in tables, and abstract the applications sql statements into higher order sql combinations. <br /><br />this does not happen often in practice, because it is essentially creating an API for the application's database and unless ad-hoc queries are the rule, the universe of query statements in most applications becomes static over time. <br /><br />In general, I have found that having to go into code and tweak sql over and over is caused by a changing database. And if that is the case, it means the database is incomplete - an incomplete semantic representation of the users data "world".<br /><br />at some point, this changing slows or stops entirely, and the employed sql becomes very static. The beauty of SQL is that it will be quite portable to a new language when the old one dies off.<br /><br />I've seen single SQL statements replace whole RPG (and Cobol!) programs. It is a very good (though not perfect) interface to an RDBMS. Other interfaces will always be language or RDBMS specific. And for this reason, those platforms will suffer "isolation" problems. (this is exactly the problem faced by the iSeries/AS400)Unknownhttps://www.blogger.com/profile/01709871637274358572noreply@blogger.comtag:blogger.com,1999:blog-35275067.post-22904184436609478452009-04-22T17:53:00.000-05:002009-04-22T17:53:00.000-05:00I'd suggest building your API on top of an rdf tri...I'd suggest building your API on top of an rdf triple store.Anonymoushttps://www.blogger.com/profile/08825321365802833225noreply@blogger.com