12 ms·

Why Programmers Don't Like Relational Databases

43 points by mqt 19y ago

mojuba 19y ago
An intriguing topic, nice try, but the author failed to explain the reasons why programmers hate databases. It's definitely not because we don't know the relational theory (I beg your pardon, but screw relational theory, it's as ugly as DBs themselves). One problem I can think of is that I'm forced to mix two languages in one story (a program, that is). It's like writing an essay in English over-peppered with a lot of Latin phrases and sayings. In web development it gets even worse: as if my favorite programming language X plus SQL wasn't enough, I mix up HTML, CSS and JavaScript - that's at least 5 languages in total! Another problem is that from a programmer's perspective databases are, put simply, arrays possibly with pointers. The only reason we can't declare these structures as arrays/lists with pointers is that data can grow infinitely big and my favorite language X can't handle that. In other words, using databases is a classical example of premature optimization that comes at a price of overcomplicated code. Yes, databases are plain arrays and even the best relational advocate can't prove the opposite (or I'd be glad to hear arguments actually). Upd: persistence and a possibility to share data between processes is another reason we use databases, but I'm sure there are more elegant ways of doing this.
- jimm 19y ago
  I agree with some of your points, but you need to study data structures a bit more. Just because a simple table structure could be implemented as an array doesn't mean that database tables are equivalent to arrays. A primary key is not the same as array index: it can be a type other than integer, and it can be non-consecutive. Indexing columns (including but not limited to the primary key) provides searches that happen in less than linear time. You can't do that with a plain array. Another thing database give you is ACID storage. Sure, you could reproduce some of that using thread-level locking or some other locking mechanism, but then what you have isn't a simple array any more.
  - mojuba 19y ago
    You can't do that with a plain array I can do that with hash arrays. The primary key is my primary hash, other keys are just extra hash maps pointing to the main array. I understand, perhaps none of the existing languages can fully replace the DB functionality, but I suspect nobody is even thinking about that because - hey, there are plenty of nice DBMSs around, why bother reinventing them? but then what you have isn't a simple array any more True, but again, it's a matter of having an infrastructure that handles sharing for you. Windows Registry, however awkward and Microsoft'ish, does just that, as as example.
    - nostrademons 19y ago
      "I can do that with hash arrays. The primary key is my primary hash, other keys are just extra hash maps pointing to the main array." A.k.a an in-memory table with hash indexes. MySQL has them. ;-) You're still missing out on a lot of functionality (even besides transactions/persistence/concurrency). For example, what if you want all records where the creation date is between a certain range of days? Or how about the maximum value of a certain column? How about joins? A conventional database can retrieve these from the indexes, but your multiple-hashes system would require a full table scan.
      - mojuba 19y ago
        All you just said is map/reduce, possibly optimized for large data chunks internally. In fact if we create a proper infrastructure, "indexing" can be done automatically and transparently. And I never said arrays should be in memory entirely, even though I declare them as arrays in my language.
        brlewis 19y ago
        SQL indexes work transparently. Creating them automatically would not be good, since they have a cost for write operations.
- Kaizyn 19y ago
  The relational model is simply the application of set theory and predicate logic to data management. Are you saying that these two branches of math/logic are ugly or that you don't understand them well enough to have a decent opinion?
- olavk 19y ago
  Databases are not arrays, although they may be implemented as arrays. The whole point of the relational model is that the logical model is abstracted from the implementation. So if e.g. the DBA decides that it would be more efficient to store a table as an array of columns rather than an array of rows, he can do that without changing the logical model.
- nostrademons 19y ago
  I don't understand the resistance to using multiple languages in one project. Every time you use an API, you're effectively using a new language. The syntax may be familiar, but the vocabulary is completely different. That's the point - through libraries and DSLs, we extend the capabilities of the base language so it's more suitable to the problem domain. Take a look at the following SQLAlchemy code: select([users.c.first_name + ' ' + users.c.last_name, users.c.email, games.c.title], from_obj=[users.join(games, users.c.user_id == games.c.creator_id], and_(games.c.creation_date == datetime.datetime.now() - datetime.timedelta(3), or_(users.c.email.like('%@aol.com'), users.c.email.like('%@hotmail.com')))) Can you really say that's easier to read than this? SELECT users.first_name + ' ' + users.last_name, users.email, games.title FROM users INNER JOIN games ON (users.user_id = games.game_id) WHERE games.creation_date >= DATE_SUB(NOW(), INTERVAL 3 DAY) AND (users.email LIKE '%@aol.com' OR users.email LIKE '%@hotmail.com') SQLAlchemy is a really cool library - it basically lets you write all your SQL queries in 100% Pure Python. But I doubt I'd use it on my own projects, because I've learned to be suspicious of libraries whose only purpose is to make some other tool look like a language I already know. Invariably there are reasons why the original language looked the way it did, and the reimplementation as a library becomes incredibly clunky as things get more complicated. I find I'm better off learning the original language instead.
  - olavk 19y ago
    My theory is that there is two kinds of people. Those that like everything to be in the same language and environment, and those that like to combine lots of different languages where each language is optimized for a specific task.
    - nostrademons 19y ago
      Could be. I'm reminded of the two competing camps for large-scale systems design. The UNIX philosophy is "small pieces loosely joined": each component does one thing well, and the system just provides a common metaphor and architecture for them to work together (eg. pipes and line-oriented text). The Windows philosophy is "big chunks tightly coupled": everything just works out of the box, but if you need to do something the designers didn't think of, you're out of luck. Kinda like "I'll do it myself; show me how" vs. "Do it for me." Nearly every computing system can be placed somewhere along this continuum. In operating systems, we've got MacOS (pre-X) and Windows on one side and UNIX on the other. In languages, we've got Scheme and Smalltalk on the UNIX side and Java and .NET on the other (ironically, Scheme and Smalltalk have a "small pieces loosely coupled" architecture internally, but are big monolithic chunks when it comes to the outside world). For IDEs, Emacs is all the way over on the UNIX side, vim not far behind, Eclipse is in the middle, and IntelliJ and Visual Studio all the way on the Windows side. For JavaScript libraries, YUI/Mootools/Prototype are all on the Windows side and JQuery is on the UNIX side, though it's moving closer to the Windows philosophy. Among web frameworks, Rails and Django are on the Windows side with Pylons on the UNIX side. The web itself is based on the UNIX philosophy, but many of the largest websites follow the Windows philosophy. I'm not so certain that people fit rigidly into one category though. Up until about 3-4 years ago, I was firmly in the Windows camp: I did Java programming only, I did it on a Windows machine, I used JBuilder and Eclipse to do it. Then I started branching out, mostly because I started learning about all this stuff that Java wouldn't let me get at. I think many people may follow a similar path: "do it for me" until you want to do something that the designers didn't think of, and then you have no choice to move to a "do it yourself; we'll show you how" environment.
- bootload 19y ago
  "... One problem I can think of is that I'm forced to mix two languages in one story .." Do you mean embedded? that I agree with. Embedded sucks but there are lots of techniques (abstraction) you can use to avoid them. Unavoidable is writing web based applications without using several languages. Though I can think of some lisp apps that do not (news). Do you lisp?
  - mojuba 19y ago
    No, I don't lisp, but I know you can nicely embed HTML directly into your lisp code with macros. I saw an example here at YCnews earlier and was struck by it, that was beautiful. No doubt, you can do that with SQL too, although that's just a cosmetic change. Even if your code looks lispish, you still think in DB terms - tables, relations.
- gregjor 19y ago
  I'm the author of the original article, and I admit that I failed to explain all of the reasons programmers don't like databases -- you came up with one I didn't list (don't want to use a lot of languages) and demonstrated one of the reasons I did list: Who Needs Theory? Your analogy with writing an essay is off target. If writing a program is like writing an essay in English, the SQL/database part of the program are like mathematical formulas in the essay. You could use English instead of mathematical notation but it would be far uglier, less precise, and more prone to error and misunderstanding. In a typical web application (what I've been doing for over ten years) the database part is usually the only part that can be proved correct. I can't help you overcome your misconceptions about relational theory or relational databases, or do anything about your opinion that relational theory is ugly. But you are just wrong arguing that relational databases are glorified arrays full of pointers and examples of premature optimization. The "best relational advocate" is probably Chris Date, and if you take the time to read his books you'll at least discover proof that you are wrong.
  - mojuba 19y ago
    Languages: we may be easily misled by analogies, but still, I'd try to defend my point: you are forced to use SQL only and only because the DB infrastructure can't understand your (presumably imperative) way of describing operations on large data sets. But you are just wrong arguing that relational databases are glorified arrays full of pointers and examples of premature optimization. I think the relational concepts are just a subset of what you can do with various kinds of collections in imperative languages - arrays, sets, maps. For example, I can have an array of records describing users, each of which incorporates a set of groups a user belongs to. In DB terms that's 3 tables (users, groups and membership) with one-to-many relations between them. Either way, we are describing the same concept of users and their membership in various groups. So why bother having another language?
henning 19y ago
I like databases because unless you have an unusually nice job, SQL is the closest you'll get to getting paid to use a declarative programming language.
edw519 19y ago
Now this is just stupid. I've built a career moving data out of flat files into RDBMS in order to get systems working properly (and quickly). I couldn't believe the hoops people jumped through just because of their dislike (or ignorance) of relational databases. This data base model is perfect for many applications, and can easily be mixed with other data storage technologies (if you know what you're doing.) Don't like the capabilities of your RDMBS? Then add what you need to you app. Indexing, transactions, stored procedures, audit, security, whatever. The code doesn't care where it's at. It still runs. Not pretty enough for you? Then become a mathematician or fashion designer. Otherwise, shut up and code.
- motoko 19y ago
  Seriously. What the fuck is wrong with SQL? I think people just want to bitch... just like this... yah.
  - olavk 19y ago
    Well, one drawback is that it is difficult to query tree-structured data.
    - spiralhead 19y ago
      My solution to that: store representations of trees as simple paths like "/trunk/branch/leaf1/", "/trunk/branch/leaf2/", etc. And just rely on the application layer to parse it all out into a friendly IU. When you want a specific branch, just do "select * from table where signature like '/trunk/branch/%'
      - imsteve 19y ago
        In my experience, that is obscenely slow.. Not practical whatsoever.
        spiralhead 19y ago
        not if you cache your data structures intelligently... probably not a good solution for something like PHP or Rails where you lose your application state across requests Or do you mean that using "like" is slow? i would think that it would not be as long as that column is indexed.
breck 19y ago
Isn't it because programmers are bad with all types of relationships?
- edw519 19y ago
  LOL. That's not what my probation officer said.
geebee 19y ago
I hope I don't get negged as a starry eyed Rails enthusiast, but here goes... Up until recently, I generally heard programmers complain constantly about the limitations of SQL and RDBMS's, and I heard a lot about object databases. The idea was that programmers would define objects, and the database would provide persistence for the objects. It was (and still is) a nice idea. Rails took a completely different approach, embracing the RDBMS as the model itself. Rather than creating objects and pushing the design out to the RDBMS, you define the relational structure and allow Rails to extract an object model. If you are doing basic CRUD operations, you may not have to think about SQL again, even in a reasonably complicated app, and the syntax is very clean. I just love it. And Ruby is like a beautiful flo... oh yeah, didn't want to get negged, better shut up now.
- ardit33 19y ago
  duh. Hibernate has been doing this for ages, before even rails existed. And it is a mess. You are trying to shoehorn a solution (ORM) so the database will fit the way you would like that data back. How about actually having the database start evolving just like programing languages have?
  - jimbokun 19y ago
    "How about actually having the database start evolving just like programing languages have?" What's stopping you from solving this problem? Sounds like a great entrepreneurial opportunity. Maybe you could submit a YC application.
    - ardit33 19y ago
      Haha. Maybe next year. It has taken decades to reach to the RDMS that we have today. They have improved efficienncy by time, but the inovation has stoped. Any new system, (OOD) will take years before reaches the maturity level to be used in commercial solutions. Kinda hard for a cash strapped startup. Also, there have been attempts to build OODs but they have failed, mainly b/c they way ahead of their time. What I would like to see a distributed Object Oriented Database system, that can scale at will.
sanj 19y ago
I've thought about this a bit, having had to write various ORM layers over the years. My conclusion is that OOP is conceptually built around single "objects" where RDBMSs are built around sets of "objects". The difference in nominal units is some of the basis of the impedence mismatch. Think about what it takes to do something interesting with a collection of objects in c++/java/whatever, such as pick out the subset that have a cost>n: it is a loop over the entire set. Ruby makes it prettier and cleaner, but you're still just looping. Unless you create a custom collection class that internally stores a hash organized by costs. But the creation of the new class is extra overhead because the nominal unit is the single object. The counterexample is just as instructive. To retrieve the newest 10 entries in a blog uses the LIMIT syntax in SQL, which is painfully nonstandard: http://troels.arvin.dk/db/rdbms/#select-limit http://troels.arvin.dk/db/rdbms/#select-limit Things that are simple in one space are hard in the other. In my own work I've resolved some of this by attempting to avoid abusing the "standard" ORM tools that are out there that allow designing queries in your language of choice (Rails for Ruby, Hibernate for Java). Instead, I attempt to figure out exactly what I need out of query: how to structure the SQL to give me back the exact set of data I care about. No subsequent looping in Ruby/Java allowed. That forces a line in the system between the DB and the application code where each is able to be use its nominal units in as native a way as possible.
- neilc 19y ago
  You don't need to step outside the SQL standard to retrieve the newest 10 entries in a blog -- SQL window functions (RANK(), ROW_NUMBER()) can do this, and they're part of the spec. You could also use a cursor with ORDER BY.
  - sanj 19y ago
    I don't believe that row_number() is standard, and I thought it couldn't be relied on for being monotonically increasing with inserts. It will also fail if you need to use a date column that may not be ordered by time. And, for me at least, cursors are definitely in the range of "advanced-ish" SQL. My point isn't that it can't be done -- empirically, many blogs do it -- but that it points to part of the impedance mismatch.
deleted 19y ago
[deleted]

43 points by mqt 19y ago

An intriguing topic, nice try, but the author failed to explain the reasons why programmers hate databases. It's definitely not because we don't know the relational theory (I beg your pardon, but screw relational theory, it's as ugly as DBs themselves). One problem I can think of is that I'm forced to mix two languages in one story (a program, that is). It's like writing an essay in English over-peppered with a lot of Latin phrases and sayings. In web development it gets even worse: as if my favorite programming language X plus SQL wasn't enough, I mix up HTML, CSS and JavaScript - that's at least 5 languages in total! Another problem is that from a programmer's perspective databases are, put simply, arrays possibly with pointers. The only reason we can't declare these structures as arrays/lists with pointers is that data can grow infinitely big and my favorite language X can't handle that. In other words, using databases is a classical example of premature optimization that comes at a price of overcomplicated code. Yes, databases are plain arrays and even the best relational advocate can't prove the opposite (or I'd be glad to hear arguments actually). Upd: persistence and a possibility to share data between processes is another reason we use databases, but I'm sure there are more elegant ways of doing this.

jimm 19y ago
I agree with some of your points, but you need to study data structures a bit more. Just because a simple table structure could be implemented as an array doesn't mean that database tables are equivalent to arrays. A primary key is not the same as array index: it can be a type other than integer, and it can be non-consecutive. Indexing columns (including but not limited to the primary key) provides searches that happen in less than linear time. You can't do that with a plain array. Another thing database give you is ACID storage. Sure, you could reproduce some of that using thread-level locking or some other locking mechanism, but then what you have isn't a simple array any more.
- mojuba 19y ago
  You can't do that with a plain array I can do that with hash arrays. The primary key is my primary hash, other keys are just extra hash maps pointing to the main array. I understand, perhaps none of the existing languages can fully replace the DB functionality, but I suspect nobody is even thinking about that because - hey, there are plenty of nice DBMSs around, why bother reinventing them? but then what you have isn't a simple array any more True, but again, it's a matter of having an infrastructure that handles sharing for you. Windows Registry, however awkward and Microsoft'ish, does just that, as as example.
  - nostrademons 19y ago
    "I can do that with hash arrays. The primary key is my primary hash, other keys are just extra hash maps pointing to the main array." A.k.a an in-memory table with hash indexes. MySQL has them. ;-) You're still missing out on a lot of functionality (even besides transactions/persistence/concurrency). For example, what if you want all records where the creation date is between a certain range of days? Or how about the maximum value of a certain column? How about joins? A conventional database can retrieve these from the indexes, but your multiple-hashes system would require a full table scan.
    - mojuba 19y ago
      All you just said is map/reduce, possibly optimized for large data chunks internally. In fact if we create a proper infrastructure, "indexing" can be done automatically and transparently. And I never said arrays should be in memory entirely, even though I declare them as arrays in my language.
      - brlewis 19y ago
        SQL indexes work transparently. Creating them automatically would not be good, since they have a cost for write operations.
Kaizyn 19y ago
The relational model is simply the application of set theory and predicate logic to data management. Are you saying that these two branches of math/logic are ugly or that you don't understand them well enough to have a decent opinion?
olavk 19y ago
Databases are not arrays, although they may be implemented as arrays. The whole point of the relational model is that the logical model is abstracted from the implementation. So if e.g. the DBA decides that it would be more efficient to store a table as an array of columns rather than an array of rows, he can do that without changing the logical model.
nostrademons 19y ago
I don't understand the resistance to using multiple languages in one project. Every time you use an API, you're effectively using a new language. The syntax may be familiar, but the vocabulary is completely different. That's the point - through libraries and DSLs, we extend the capabilities of the base language so it's more suitable to the problem domain. Take a look at the following SQLAlchemy code: select([users.c.first_name + ' ' + users.c.last_name, users.c.email, games.c.title], from_obj=[users.join(games, users.c.user_id == games.c.creator_id], and_(games.c.creation_date == datetime.datetime.now() - datetime.timedelta(3), or_(users.c.email.like('%@aol.com'), users.c.email.like('%@hotmail.com')))) Can you really say that's easier to read than this? SELECT users.first_name + ' ' + users.last_name, users.email, games.title FROM users INNER JOIN games ON (users.user_id = games.game_id) WHERE games.creation_date >= DATE_SUB(NOW(), INTERVAL 3 DAY) AND (users.email LIKE '%@aol.com' OR users.email LIKE '%@hotmail.com') SQLAlchemy is a really cool library - it basically lets you write all your SQL queries in 100% Pure Python. But I doubt I'd use it on my own projects, because I've learned to be suspicious of libraries whose only purpose is to make some other tool look like a language I already know. Invariably there are reasons why the original language looked the way it did, and the reimplementation as a library becomes incredibly clunky as things get more complicated. I find I'm better off learning the original language instead.
- olavk 19y ago
  My theory is that there is two kinds of people. Those that like everything to be in the same language and environment, and those that like to combine lots of different languages where each language is optimized for a specific task.
  - nostrademons 19y ago
    Could be. I'm reminded of the two competing camps for large-scale systems design. The UNIX philosophy is "small pieces loosely joined": each component does one thing well, and the system just provides a common metaphor and architecture for them to work together (eg. pipes and line-oriented text). The Windows philosophy is "big chunks tightly coupled": everything just works out of the box, but if you need to do something the designers didn't think of, you're out of luck. Kinda like "I'll do it myself; show me how" vs. "Do it for me." Nearly every computing system can be placed somewhere along this continuum. In operating systems, we've got MacOS (pre-X) and Windows on one side and UNIX on the other. In languages, we've got Scheme and Smalltalk on the UNIX side and Java and .NET on the other (ironically, Scheme and Smalltalk have a "small pieces loosely coupled" architecture internally, but are big monolithic chunks when it comes to the outside world). For IDEs, Emacs is all the way over on the UNIX side, vim not far behind, Eclipse is in the middle, and IntelliJ and Visual Studio all the way on the Windows side. For JavaScript libraries, YUI/Mootools/Prototype are all on the Windows side and JQuery is on the UNIX side, though it's moving closer to the Windows philosophy. Among web frameworks, Rails and Django are on the Windows side with Pylons on the UNIX side. The web itself is based on the UNIX philosophy, but many of the largest websites follow the Windows philosophy. I'm not so certain that people fit rigidly into one category though. Up until about 3-4 years ago, I was firmly in the Windows camp: I did Java programming only, I did it on a Windows machine, I used JBuilder and Eclipse to do it. Then I started branching out, mostly because I started learning about all this stuff that Java wouldn't let me get at. I think many people may follow a similar path: "do it for me" until you want to do something that the designers didn't think of, and then you have no choice to move to a "do it yourself; we'll show you how" environment.
bootload 19y ago
"... One problem I can think of is that I'm forced to mix two languages in one story .." Do you mean embedded? that I agree with. Embedded sucks but there are lots of techniques (abstraction) you can use to avoid them. Unavoidable is writing web based applications without using several languages. Though I can think of some lisp apps that do not (news). Do you lisp?
- mojuba 19y ago
  No, I don't lisp, but I know you can nicely embed HTML directly into your lisp code with macros. I saw an example here at YCnews earlier and was struck by it, that was beautiful. No doubt, you can do that with SQL too, although that's just a cosmetic change. Even if your code looks lispish, you still think in DB terms - tables, relations.
gregjor 19y ago
I'm the author of the original article, and I admit that I failed to explain all of the reasons programmers don't like databases -- you came up with one I didn't list (don't want to use a lot of languages) and demonstrated one of the reasons I did list: Who Needs Theory? Your analogy with writing an essay is off target. If writing a program is like writing an essay in English, the SQL/database part of the program are like mathematical formulas in the essay. You could use English instead of mathematical notation but it would be far uglier, less precise, and more prone to error and misunderstanding. In a typical web application (what I've been doing for over ten years) the database part is usually the only part that can be proved correct. I can't help you overcome your misconceptions about relational theory or relational databases, or do anything about your opinion that relational theory is ugly. But you are just wrong arguing that relational databases are glorified arrays full of pointers and examples of premature optimization. The "best relational advocate" is probably Chris Date, and if you take the time to read his books you'll at least discover proof that you are wrong.
- mojuba 19y ago
  Languages: we may be easily misled by analogies, but still, I'd try to defend my point: you are forced to use SQL only and only because the DB infrastructure can't understand your (presumably imperative) way of describing operations on large data sets. But you are just wrong arguing that relational databases are glorified arrays full of pointers and examples of premature optimization. I think the relational concepts are just a subset of what you can do with various kinds of collections in imperative languages - arrays, sets, maps. For example, I can have an array of records describing users, each of which incorporates a set of groups a user belongs to. In DB terms that's 3 tables (users, groups and membership) with one-to-many relations between them. Either way, we are describing the same concept of users and their membership in various groups. So why bother having another language?

henning 19y ago

I like databases because unless you have an unusually nice job, SQL is the closest you'll get to getting paid to use a declarative programming language.

edw519 19y ago

Now this is just stupid. I've built a career moving data out of flat files into RDBMS in order to get systems working properly (and quickly). I couldn't believe the hoops people jumped through just because of their dislike (or ignorance) of relational databases. This data base model is perfect for many applications, and can easily be mixed with other data storage technologies (if you know what you're doing.) Don't like the capabilities of your RDMBS? Then add what you need to you app. Indexing, transactions, stored procedures, audit, security, whatever. The code doesn't care where it's at. It still runs. Not pretty enough for you? Then become a mathematician or fashion designer. Otherwise, shut up and code.

motoko 19y ago
Seriously. What the fuck is wrong with SQL? I think people just want to bitch... just like this... yah.
- olavk 19y ago
  Well, one drawback is that it is difficult to query tree-structured data.
  - spiralhead 19y ago
    My solution to that: store representations of trees as simple paths like "/trunk/branch/leaf1/", "/trunk/branch/leaf2/", etc. And just rely on the application layer to parse it all out into a friendly IU. When you want a specific branch, just do "select * from table where signature like '/trunk/branch/%'
    - imsteve 19y ago
      In my experience, that is obscenely slow.. Not practical whatsoever.
      - spiralhead 19y ago
        not if you cache your data structures intelligently... probably not a good solution for something like PHP or Rails where you lose your application state across requests Or do you mean that using "like" is slow? i would think that it would not be as long as that column is indexed.

breck 19y ago

Isn't it because programmers are bad with all types of relationships?

edw519 19y ago
LOL. That's not what my probation officer said.

geebee 19y ago

I hope I don't get negged as a starry eyed Rails enthusiast, but here goes... Up until recently, I generally heard programmers complain constantly about the limitations of SQL and RDBMS's, and I heard a lot about object databases. The idea was that programmers would define objects, and the database would provide persistence for the objects. It was (and still is) a nice idea. Rails took a completely different approach, embracing the RDBMS as the model itself. Rather than creating objects and pushing the design out to the RDBMS, you define the relational structure and allow Rails to extract an object model. If you are doing basic CRUD operations, you may not have to think about SQL again, even in a reasonably complicated app, and the syntax is very clean. I just love it. And Ruby is like a beautiful flo... oh yeah, didn't want to get negged, better shut up now.

ardit33 19y ago
duh. Hibernate has been doing this for ages, before even rails existed. And it is a mess. You are trying to shoehorn a solution (ORM) so the database will fit the way you would like that data back. How about actually having the database start evolving just like programing languages have?
- jimbokun 19y ago
  "How about actually having the database start evolving just like programing languages have?" What's stopping you from solving this problem? Sounds like a great entrepreneurial opportunity. Maybe you could submit a YC application.
  - ardit33 19y ago
    Haha. Maybe next year. It has taken decades to reach to the RDMS that we have today. They have improved efficienncy by time, but the inovation has stoped. Any new system, (OOD) will take years before reaches the maturity level to be used in commercial solutions. Kinda hard for a cash strapped startup. Also, there have been attempts to build OODs but they have failed, mainly b/c they way ahead of their time. What I would like to see a distributed Object Oriented Database system, that can scale at will.

sanj 19y ago

I've thought about this a bit, having had to write various ORM layers over the years. My conclusion is that OOP is conceptually built around single "objects" where RDBMSs are built around sets of "objects". The difference in nominal units is some of the basis of the impedence mismatch. Think about what it takes to do something interesting with a collection of objects in c++/java/whatever, such as pick out the subset that have a cost>n: it is a loop over the entire set. Ruby makes it prettier and cleaner, but you're still just looping. Unless you create a custom collection class that internally stores a hash organized by costs. But the creation of the new class is extra overhead because the nominal unit is the single object. The counterexample is just as instructive. To retrieve the newest 10 entries in a blog uses the LIMIT syntax in SQL, which is painfully nonstandard: http://troels.arvin.dk/db/rdbms/#select-limit http://troels.arvin.dk/db/rdbms/#select-limit Things that are simple in one space are hard in the other. In my own work I've resolved some of this by attempting to avoid abusing the "standard" ORM tools that are out there that allow designing queries in your language of choice (Rails for Ruby, Hibernate for Java). Instead, I attempt to figure out exactly what I need out of query: how to structure the SQL to give me back the exact set of data I care about. No subsequent looping in Ruby/Java allowed. That forces a line in the system between the DB and the application code where each is able to be use its nominal units in as native a way as possible.

neilc 19y ago
You don't need to step outside the SQL standard to retrieve the newest 10 entries in a blog -- SQL window functions (RANK(), ROW_NUMBER()) can do this, and they're part of the spec. You could also use a cursor with ORDER BY.
- sanj 19y ago
  I don't believe that row_number() is standard, and I thought it couldn't be relied on for being monotonically increasing with inserts. It will also fail if you need to use a date column that may not be ordered by time. And, for me at least, cursors are definitely in the range of "advanced-ish" SQL. My point isn't that it can't be done -- empirically, many blogs do it -- but that it points to part of the impedance mismatch.

deleted 19y ago

[deleted]