Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Databases Programming Software IT Technology

Is the Relational Database Doomed? 344

Posted by ScuttleMonkey from the just-more-tools-in-the-bucket dept.
DB Guy writes "There's an article over on Read Write Web about what the future of relational databases looks like when faced with new challenges to its dominance from key/value stores, such as SimpleDB, CouchDB, Project Voldemort and BigTable. The conclusion suggests that relational databases and key value stores aren't really mutually exclusive and instead are different tools for different requirements."
This discussion has been archived. No new comments can be posted.

Is the Relational Database Doomed? More

Is the Relational Database Doomed?

Comments Filter:

  • new record (Score:5, Interesting)

    by hguorbray ( 967940 ) on Friday February 13, 2009 @04:14PM (#26849365)

    that's efficient -a summary that refutes the inflammatory headline

    I'm just sayin'

    • Re:new record (Score:4, Funny)

      by Jah-Wren Ryel ( 80510 ) on Friday February 13, 2009 @04:21PM (#26849477)

      Yeaah. Only if you did not know the meaning of the '?' symbol.

    • Re:new record (Score:5, Funny)

      by julesh ( 229690 ) on Friday February 13, 2009 @05:06PM (#26850099)

      that's efficient -a summary that refutes the inflammatory headline

      I'm just sayin'

      Nah. Efficient would be if the summary were "No."

    • Here's a match.. (Score:3, Interesting)

      by Slicker ( 102588 )

      Relational databases need to die. I loved them and preached the goodness of them 10 years ago, but they are just too rigid for contemporary needs. I've learned better ways of organizing and filtering data.. but the old RDBMS school is too canonical (stubborn) and self-indulging to realize that needs are changing and their model doesn't fit.

      We need efficient attribute/value models. We need to stop referencing data by where it is and start referencing it by what it is. There is too much data that needs to

      • Re: (Score:3, Insightful)

        by lgw ( 121541 )

        What do you mean by "informatin, not just data"? It seems like you have specific, personal definitions of those words that others might not share.

        If you make sorting the responsibility of the client, what do you do with large result sets? You can't sort chunked data client-side, as you have to sort before chunking. There should be *some* answer for result sets that don't fit in memory (client or server). I'd be happy with only being able to get results in a certain order if I've already built an index a

      • Re:Here's a match.. (Score:5, Informative)

        by DarkOx ( 621550 ) on Friday February 13, 2009 @06:38PM (#26851083) Journal

        Wow, um where to being really....

        So you realize that the structure you are suggesting can be easily built in a traditional RDB, using a star-schema or cluster design right?

        Next you suggest doing the sorting on the client, and then say that if there is more data then a client can handle the server can be asked to send chunks according to the clients sort order. That means the server has to have all the sort logic the client has and probably in all but the most trival applications do all the sorting anyway... Seems to me a star schema and indexing the fact table on the attributes that are most comonly going to be used for sorting makes much more sense; because as I said the serve is going to be sorting anyway.

        Now there are data sets that non relational structers do make some more sense, but we have hierarchy , and navigational designes for those, yours is not one of them.

      • Re:Here's a match.. (Score:4, Insightful)

        by jadavis ( 473492 ) on Saturday February 14, 2009 @12:19PM (#26856659)

        We need to stop referencing data by where it is and start referencing it by what it is.

        You say that without any explanation of your apparent position that the relational model requires you to reference data by "where it is".

        You seem to think that the semantics of your system are somehow richer -- providing "information" rather than "data".

        Do you even know what a relation is?

  • Headline: Is the Relational Database Doomed?

    Summary: "The conclusion being that relational databases and key value stores aren't really mutually exclusive and instead are different tools for different requirements."

    WTF?

    • Re: (Score:3, Insightful)

      by Lord Ender ( 156273 )

      If "key/value" databases do become more popular, they certainly might eat in to relational database mindshare. 90% of web applications use RDMSs merely as persistent data storage--the fact that they are "relational" doesn't matter at all; the fact that a separate SQL language is needed to get the data (rather than using language-native data structures as an interface) is even a negative for RDMs.

      As a web app developer, I'm excited that something other than SQL is getting attention. RDMSs won't go away becau

      • Re: (Score:3, Insightful)

        by ultranova ( 717540 )

        If "key/value" databases do become more popular, they certainly might eat in to relational database mindshare.

        A "key/value" database is simply a relational database with a single table and two columns. It doesn't make any sense to build a separate server program for what current database servers can already easily do.

        90% of web applications use RDMSs merely as persistent data storage--the fact that they are "relational" doesn't matter at all; the fact that a separate SQL language is needed to get the data

  • Uh-oh (Score:5, Funny)

    by benjymouse ( 756774 ) on Friday February 13, 2009 @04:16PM (#26849403)
    Someone forgot to put a where clause on that delete.

  • Yes, but not soon. (Score:4, Interesting)

    by pwnies ( 1034518 ) * <j@jjcm.org> on Friday February 13, 2009 @04:17PM (#26849419) Homepage Journal
    The flexibility offered in key/value databases is simply too good of a feature to pass up. However, do you really think you can get people to give up MSSQL? It'll be nice for smaller projects, but corporations wont even consider it for a number of years.

    • Re:Yes, but not soon. (Score:4, Interesting)

      by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Friday February 13, 2009 @04:24PM (#26849503) Journal

      do you really think you can get people to give up MSSQL?

      In favor of MySQL, PostgreSQL, SQLite, even Oracle, yes, I do.

      corporations wont even consider it for a number of years.

      You must have some specific corporations in mind, because I've known many corporations to use each of the above technologies. In fact, SQLite is one of the most popular databases ever.

      No, the reason it's not soon is because these other ones (CouchDB) aren't mature, and the ones that are (BigTable) aren't available at any price.

      • Re:Yes, but not soon. (Score:4, Informative)

        by encoderer ( 1060616 ) on Saturday February 14, 2009 @01:12AM (#26853695)

        Suggesting that you could replace a MS-SQL server with SQLite basically forces anybody in the know to ignore every other point you make.

        MySQL is good, unless you need a highly performent query analyzer.

        Postgres is good, unless you need actual replication features.

        SQLite is good, if your datastore is less than 1GB.

        Oracle is no-doubt a valid replacement and improvement upon SQL Server. And I use MySQL more than any other DB. But you need to hire Percona to get the same performance out of MySQL that you get from SQL Server out of the box.

        • Re:Yes, but not soon. (Score:4, Informative)

          by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Saturday February 14, 2009 @01:51AM (#26853877) Journal

          Suggesting that you could replace a MS-SQL server with SQLite basically forces anybody in the know to ignore every other point you make.

          You're assuming that the person using MS-SQL Server knows what they're doing. How do you know it's more than just a glorified Access database?

          MySQL is good, unless you need a highly performent query analyzer.

          In other words, the query analyzer is slow? Because the queries work well enough.

          Postgres is good, unless you need actual replication features.

          Like these [tinyurl.com]?

          SQLite is good, if your datastore is less than 1GB.

          Another quick Google, and we find these limits [sqlite.org] -- by default, the maximum database size is just under 32 terabytes.

          Not that I'm suggesting it's a good choice at that point, especially with multiple processes. But it does make it kind of hard to take you seriously with that kind of imagined limit, unless you're suggesting there's a practical, performance wall after 1 gig.

        • Re: (Score:3, Interesting)

          by anothy ( 83176 )

          But you need to hire Percona to get the same performance out of MySQL that you get from SQL Server out of the box.

          this has not been my experience. at least with version 8 (two back from current), performance was miserable compared to either mysql or postgresql of comparable vintage. this was my first serious experience using mssql, but with no tuning on either side, both mysql and postgresql outperformed mssql by a factor of about 2.
          while we never got the database on the production system swapped out (devel

    • Re:Yes, but not soon. (Score:5, Informative)

      by Eravnrekaree ( 467752 ) on Friday February 13, 2009 @05:14PM (#26850223)

      Actually i read TFA, and I just couldnt make sense of the benefits offered by the key value thing. You basically should be able to get the same benefits with a relational database system with a query that does a lookup on a single column index. This would involve searching the b-tree for that column, which would yield a row data address of some sort, to either a linked list of cells or a list of addresses of those cells. Once the single b-tree is done it is then very fast to find the other column values in that row. The b-tree or other index lookup also has to be done with the key value pair, the relational is just a collection of multiple key value indexes.

      There is the issue of having a variable number of pieces of data linked to a certain key. But you can do this in relational too. Just create a table with an id column, value type column and value column. A well designed relational, if you do a query on the id column, the b-tree will lead to data which has all of the row data addresses in the database that match the id. EAch of those rows will contain a different data type/data payload for the id. This is again pretty much as fast as a simple single index database.

      • Re:Yes, but not soon. (Score:5, Interesting)

        by photon317 ( 208409 ) on Friday February 13, 2009 @06:16PM (#26850865)

        Yes, these newer simple key/value databases like BigTable and CouchDB are effectively a subset of RDBMS functionality, so of course the same thing can be implemented relationally by just not using features.

        The reason these projects have taken off is that the relational features being skipped comprise most of the complexity of an RDBMS. Without them, it's relatively trivial to write new database engines from scratch instead of re-using MySQL, PostgreSQL, and so-on. These new feature-poor rewrites can take on many challenges that are harder for the big relational guys, like stellar performance on huge datasets, and being truly distributed in nature.

        • Re: (Score:3, Insightful)

          by Estanislao Martínez ( 203477 )

          Yes, these newer simple key/value databases like BigTable and CouchDB are effectively a subset of RDBMS functionality, so of course the same thing can be implemented relationally by just not using features.

          What worries me about these arguments, however, is that they're missing a point that's very similar to yours here: these high-performance key-value databases can be implemented as features in an RDBMS. Basically, if you have a technology that allows some limited type of database to be distributed across

  • No (Score:2)

    by Azarael ( 896715 )
    It isn't up for debate that tupple stores are a very useful tool. That being said, they aren't a silver bullet for *ALL* data storage situations. For types of data that are inherently tabular, I really doubt that 40 years of RDBMS development will be trumped by a tuple store. When you move to hierarchical data though, things are reversed.

  • Top 25 Reasons the Relational Database is Doomed (Score:5, Funny)

    by MillionthMonkey ( 240664 ) on Friday February 13, 2009 @04:18PM (#26849433)

    Someone type this up and submit it to Digg.

  • Hey! (Score:4, Insightful)

    by MightyMartian ( 840721 ) on Friday February 13, 2009 @04:20PM (#26849453) Journal

    Hey, read my article! Just to make sure you do, I'll pull a Dvorak and put in some incredibly sensational headline about how RDBMs are dewmed!!!!!! BWAHAHA, feed my advertisers!!!!

    (Tune in ext week, when I write about how C programming is going to become extinct in the light of fantastic new development tools like C# and Ruby on Rails!!!)

  • Voldemort! (Score:3, Funny)

    by GreatRedShark ( 880833 ) on Friday February 13, 2009 @04:27PM (#26849553)

    There's a db called Project Voldemort? That's awesome! I'm switching to that just for the name! I think my manager is a Harry Potter fan so getting approval shouldn't be too hard.

  • Enough with the death of the relational DB (Score:5, Interesting)

    by Mr. Underbridge ( 666784 ) on Friday February 13, 2009 @04:27PM (#26849561)
    This same basic story keeps getting submitted from the same group of people who are generally trying to sell non-relational-DB stuff. This is an ad. Move along.

  • 99.9% of databases... (Score:4, Interesting)

    by Ckwop ( 707653 ) on Friday February 13, 2009 @04:29PM (#26849585) Homepage

    99.9% of database claim to follow the relational model.

    The rest have scalability problems that 99.9% of developers will never see throughout their entire careers.

    So the answer is a simple, emphatic, no.

    • Re: (Score:3, Interesting)

      by arevos ( 659374 )

      99.9% of database claim to follow the relational model.

      The rest have scalability problems that 99.9% of developers will never see throughout their entire careers.

      Uh, actually, relational databases are pretty damn hard to scale. That's basically the main problem with them. Why do you think relational databases are so often paired with a cache made from a hashtable-based database?

  • Finally the OODB people will (Score:5, Insightful)

    by thammoud ( 193905 ) on Friday February 13, 2009 @04:29PM (#26849587)

    Leave us RDBMS dinosaurs alone. String Name/Value pairs, that is a great innovation. In other news, Sun will be dropping all types from the Java object system and rely on the VOID type. Idiots.

  • The conclusion being that relational databases and key value stores aren't really mutually exclusive and instead are different tools for different requirements.

    In related news, black is not white.

  • A great open source implementation (Score:5, Funny)

    by thammoud ( 193905 ) on Friday February 13, 2009 @04:33PM (#26849647)

    Map db = new HashMap();

    beginTransaction(); // Synchronize on the map
    db.add("key", "value");
    commitTransaction(); // Just serialize the fucker to a file. The idiots using this won't know the difference.

    • Re: (Score:2)

      by julesh ( 229690 )

      commitTransaction(); // Just serialize the fucker to a file. The idiots using this won't know the difference.

      You've come across prevayler then?

  • ah, stupid. (Score:3)

    by tjstork ( 137384 ) <todd.bandrowskyNO@SPAMgmail.com> on Friday February 13, 2009 @04:42PM (#26849775) Homepage Journal

    The big dumb thing about key store values is that they are actually just a subset of relational algebra in theory and are thus readily implementable in a relational database in fact. If you really wanted to have a database just do key / store values, you could quite easily do that in any rdms.

    • Re:ah, stupid. (Score:4, Insightful)

      by poot_rootbeer ( 188613 ) on Friday February 13, 2009 @04:57PM (#26849993)

      If you really wanted to have a database just do key / store values, you could quite easily do that in any rdms.

      Sure, but it's not likely that a key/value store implemented within a general-purpose RDBMS can achieve the same raw performance that a system designed to do nothing but implement a key/value store -- nor the distributability, for that matter.

  • In relation to what? (Score:5, Funny)

    by Penguinshit ( 591885 ) on Friday February 13, 2009 @04:46PM (#26849837) Homepage Journal
    I won't believe it until Netcraft confirms it.

  • This is an old argument which will not fly (Score:5, Informative)

    by bogaboga ( 793279 ) on Friday February 13, 2009 @04:48PM (#26849855)

    It has been suggested before that the life of the relational DB is coming to an end. I must say that while I agree with this statement: -

    Relational databases scale well, but usually only when that scaling happens on a single server node. When the capacity of that single node is reached, you need to scale out and distribute that load across multiple server nodes. This is when the complexity of relational databases starts to rub against their potential to scale.

    I disagree with the following statement: -

    Try scaling to hundreds or thousands of nodes, rather than a few, and the complexities become overwhelming, and the characteristics that make RDBMS so appealing drastically reduce their viability as platforms for large distributed systems.

    I submit that the complexity can be managed and that's why we have jobs.

    I am an IT consultant at a major bank and we keep all kinds of data. Data that many find useless and is spread across 27 [major] nodes. Total records in our biggest table number about 57 million with 49 rows. I can tell you that data querying and integrity maintaining are a breeze if the schematic design is correct in the first place.

    We are always designing and testing different scenarios. In cases where we have had to change the schema, it has been simple if one knows what to do.

    I must say that Open Source DBs have worked for us though we rely on products from IBM and Oracle.

    Our philosophy is: If it works in PostgreSQL, it will even do wonders on DB2 or Oracle. I do not see how we can do away with the relational DB. Whoever designed it in the beginning did a marvelous job.

  • Ridiculous (Score:4, Insightful)

    by Eravnrekaree ( 467752 ) on Friday February 13, 2009 @04:49PM (#26849877)

    Really rational is the best way to take a data set and be able to access it in various ways. Many of the other concepts are indeed regressions and reintroduce problems a relational database solves. Relational allows you to able to display and view data in various different ways and apply the dataset in new ways, ways that may not have originally been a part of the original design of the application. Every time we hear someone harp about some new database technology that reintroduces all of the problems of the past, but relational is still the best and most versatile way to store your data in a way that allows for query flexibility.

  • Is the automobile doomed? (Score:3, Insightful)

    by Renegade Iconoclast ( 1415775 ) on Friday February 13, 2009 @04:51PM (#26849895)

    Turns out, there's something called a "skateboard." You can use it to travel as far as the Quickie Mart, with nothing but your feet to propel it.

    In conclusion, skateboards and automobiles aren't the same thing, so probably not.

  • Seriously? Get the Harry Potter out. Out now!

  • Supid people who don't understand data (Score:5, Informative)

    by mlwmohawk ( 801821 ) on Friday February 13, 2009 @05:05PM (#26850079)

    The relational database is not going anywhere and nothing in that article is based on any firm understanding of managing data.

    Is the notion of a "join" obsolete? No, but it is typically impractical in a high volume system. You would probably use denormalization as a strategy.

    Scaling many nodes? OK, you still gotta put your data "in" something.

    key/value indexing? yawn. select val from keyvalue_tab where key = foo;

    The value can be basically anything, and most "relational" databases have good object support as well as XML, JSON, etc.

    So we can establish that a SQL relational database can do *everything* a simpler system can do. Now, think about ALL the things you can do with your data in a real database.

    What is the point of using a limited and less functional system? A good system, like Oracle, DB2, PostgreSQL, etc (!mysql of course) will do what you need AND allow you do do more should you be successful.

    The problem with data is two fold: Managing read/write/deletes and finding what you are looking for. These problems have been solved. A good database will do this for you. Want to store object? XML, JSON, binary objects, or a specialized database extension works perfectly.

    • Re:Supid people who don't understand data (Score:5, Insightful)

      by sl0ppy ( 454532 ) on Friday February 13, 2009 @05:21PM (#26850285)

      The relational database is not going anywhere and nothing in that article is based on any firm understanding of managing data.

      no, the relational database is not going anywhere, you are correct. but, that does not mean that there aren't instances where a non-relational database, with the addition of map/reduce, aren't extremely useful.

      non-relational databases have been around for decades, and are in use for quite a number of applications involving rapid development and storage of very large records. couple this with map/reduce, and you have the ability to scale quickly with very large datasets.

      scaling quickly is a very difficult problem to solve with an RDBMS - you either need to continue to throw more hardware at the problem, to the point of diminishing returns, or re-architect your data at the cost of possible significant downtime, while still attempting to serve up the data in a timely manner. i've been deep in the bowels of oracle RAC, fighting to get just 5% more speed out of a query over a billion rows and realizing that i have to start over with a new schema, just to squeeze more data out. compare that to simply adding another machine and letting the map functionality run across one more cpu before returning it for the reduce.

      Is the notion of a "join" obsolete? No, but it is typically impractical in a high volume system. You would probably use denormalization as a strategy.

      once again, correct, but having to denormalize to a snowflake or a star isn't always the best solution. you're taking the best parts of the relational database model, and throwing them out - normalization, referential integrity, just to squeeze more out of something that may not be the best tool for the job.

      do you hammer with a wrench? i have before, and i managed to hurt my thumb.

      • Re: (Score:3, Insightful)

        by Matt Perry ( 793115 )

        do you hammer with a wrench? i have before, and i managed to hurt my thumb.

        Not usually, but I have done so before. If it hurts your thumb, you're holding it wrong.

    • Re: (Score:3, Insightful)

      by DragonWriter ( 970822 )

      So we can establish that a SQL relational database can do *everything* a simpler system can do.

      In terms of expressive power, sure, but no one is arguing that distributed key/value stores are going to gain against RDBMS's because they have superior expressive power. What is being argued is that they will do so because they have superior scalability and distribution properties, and that in many real-world applications those are more important than the having the full expressive power of relational algebra. Pa

  • Some credibility... (Score:3, Insightful)

    by jernejk ( 984031 ) on Friday February 13, 2009 @05:12PM (#26850187)
    form the article: "For example, a relatively simple SELECT statement could have hundreds of potential query execution paths, which the optimizer would evaluate at run time. All of this is hidden to us as users, but under the cover, RDBMS determines the "execution plan" that best answers our requests by using things like cost-based algorithms." So, you have no idea how optimizers work and how you can access tuning information, and you'd like to tell us RDBMSs are bad? Get of my lawn! (yay, I'm getting old)

    • Re: (Score:2, Funny)

      by jernejk ( 984031 )
      no, really.. this is utter crap: so called benefit: "The first benefit is that they are simple and thus scale much better than today's relational databases. If you are putting together a system in-house and intend to throw dozens or hundreds of servers behind your data store to cope with what you expect will be a massive demand in scale, then consider a key/value store." but then:"Bugs in a properly designed relational database usually don't lead to data integrity issues; bugs in a key/value database, how

  • He can't even explain relations correctly... (Score:4, Informative)

    by iamhigh ( 1252742 ) on Friday February 13, 2009 @05:12PM (#26850195)
    Does that example of a relational DB have a serious error, or is that just me? Why have make key in two tables?

    He lost cred right then.

  • Not buying it. (Score:5, Interesting)

    by reginaldo ( 1412879 ) on Friday February 13, 2009 @05:13PM (#26850203)
    In theory, I agree the most costly actions in a database are joins. It seems like the key/value model is a great solution to this, on the surface. However, what the key/value model does is push the cost to the application layer. Instead of ensuring relational integrity and conformity in the database, suddenly all app code has to do this on the frontend. Also, instead of managing this process in a single place, suddenly this process is distributed among multiple methods. Sure, the DB is more scaleable, but suddenly the app is a mess.

  • ...or at least an attempt at bad advertising or pursuasive writing (cognitive justification.)

    OODBMS have been pushing this, and many of them are pushed as light weight key-value stores.

    http://en.wikipedia.org/wiki/ODBMS [wikipedia.org]

    This isn't new, like OpenDoc's Bento
    http://en.wikipedia.org/wiki/OpenDoc [wikipedia.org]

    That became IronDoc
    http://linuxfinances.info/info/oodbms.html [linuxfinances.info]

    The problem with any of it is that relational databases rule the enterprise space. You cannot get away from them, and they are far from dead, because you will

  • There are still multi-billion dollar businesses operating the core of their business on COBOL systems, and they're decades older than relational database technology.

    So don't bet on it.

  • Just to be pendactic (Score:4, Insightful)

    by plopez ( 54068 ) on Friday February 13, 2009 @06:55PM (#26851293) Journal

    There really isn't a true implementation of the relational model as per Codd and Date.

    Also, SQL is a nightmare. A badly designed programming language which is not quite functional and not quite procedural and so needs a bunch of hacks to work properly. And then there is the issue of NULLS. And the fact that you can end up with ugly bag operations and path dependencies in SQL.

    And just to start yet another flame war (Iknow, I just know some one is going to mod me as a troll today) key/value is just another way of saying "network database".

    And another thing which I will probably get hammered for, if you normalize a DB properly you will get you objects almost for free. And vice versa. Where I see people having problems is that they either are :

    1) lazy about defining and understanding their data
    2) or likewise for their objects
    3) or both.

    If you do it properly will will get a nice set of multidimensional objects and fact/attribute tables which are orthogonal and lean. Easy to understand, search, join, build, compose, decompose, signal and track.

    As opposed to a snarled up hacked together, overloaded, over inherited nightmare with hidden dependencies which I have seen too many times.

    OK, you can slam me now.

  • SQL is the problem, not RDBMSs (Score:4, Interesting)

    by Savantissimo ( 893682 ) on Friday February 13, 2009 @06:55PM (#26851303) Journal

    SQL and all its pointy-headed progeny are the real problem with databases, not the relational vs. newMarketingBuzzwordDuJour arguments.

    Database operations do not need to look like code or algorithms, the only reason they do is to provide jobs for database programmers.

    Over 15 years ago Paradox's query-by-example was light-years ahead of today's soul-killing SQL crap.

    SQL is not going away, though, any more than its idiot older brother Mumps (M, Caché).

    • Re: (Score:3, Insightful)

      by emurphy42 ( 631808 )

      Paradox's query-by-example

      *looks up* GUI query builder? Highly appropriate for simple things (e.g. Crystal Reports), but absolutely terrible for more complex things.

    • Re:SQL is the problem, not RDBMSs (Score:5, Informative)

      by WuphonsReach ( 684551 ) on Friday February 13, 2009 @09:56PM (#26852729)
      Over 15 years ago Paradox's query-by-example was light-years ahead of today's soul-killing SQL crap.

      QBE grids are nothing more then a UI abstraction of the underlying SQL SELECT statement. In fact, in MS-Access (which has a QBE grid), you can flip between looking at the QBE and looking at the raw SQL SELECT statement.

      Sometimes it's faster to do it in raw SQL, sometimes it's faster to setup the query in a QBE grid.

    • Re:SQL is the problem, not RDBMSs (Score:5, Insightful)

      by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Friday February 13, 2009 @10:04PM (#26852775) Homepage Journal

      Database operations do not need to look like code or algorithms, the only reason they do is to provide jobs for database programmers.

      From Wikipedia [wikipedia.org]:

      Relational database theory uses a different set of mathematical-based terms, which are equivalent, or roughly equivalent, to SQL database terminology.

      SQL looks like SQL because it's based on set theory. As an exercise, invent your own language that's as powerful (read: also based on a strong theoretical basis) but simpler. See you in a couple of decades!

  • STILL "relational" - Dynamic Relational (Score:3, Interesting)

    by Tablizer ( 95088 ) on Friday February 13, 2009 @07:03PM (#26851375) Journal

    Some of those systems appear to more or less still be "relational". If each row is treated like a map (associative array) of strings, then the "schema" for a given table is the set union of all attributes used in the table, and non-existing columns for a given row can be treated as nulls.

    As long as an asterisk is not used in a query (ex: "select * from tableX"), then it will pretty much act like existing RDBMS, and as long as the type-explicitness issues are resolved based on dynamic language conventions. (Asterisks can be implemented perhaps, but it could be computationally expensive.)

    It's kind of like dynamic (AKA "scripting") languages versus static or type-heavy languages. The static kind of languages requires more up-front info that "protects" the integrity of the thing at the expense of flexibility and declaration volume. The same dichotomy can be applied to RDBMS also. We have RDBMS that like a lot of info up-front, and now those which accept incremental or ad-hoc insertions are starting to be common (but still less standardized).

    And constraints can be incrementally added, such as later requiring that every new record in a "Cars" table have a value for "brand" or the like.

    One possible exception is that there were some examples that violated "map-ness" of records, such as having two colors for a car. If they instead supplied "color_1" and "color_2", then map set rules would not be violated, keeping it closer to true relational.

    In short: We don't have to abandon relational to get dynamism.

  • Yep, this will happen (Score:3, Funny)

    by ghjm ( 8918 ) on Friday February 13, 2009 @07:47PM (#26851805) Homepage

    I can see the meeting now.

    Developer: "Hey boss, I found a better product for the transaction processing data! It might save us a bunch of money on Oracle licenses!"
    Boss: "Great, what is it?"
    Developer: "Project Voldemort!"
    Boss: "..."
    Developer: "No really, let me explain..."
    Boss: "I have a meeting to get to, but hey, let me know if you have any other great ideas."

  • A SQL query walks into a bar... (Score:5, Funny)

    by SystematicPsycho ( 456042 ) on Friday February 13, 2009 @08:09PM (#26851975)

    A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'

    From Tom Kyte's blog sql joke [blogspot.com]

  • Object class anyone? (Score:3, Insightful)

    by kilodelta ( 843627 ) on Friday February 13, 2009 @10:56PM (#26853071) Homepage
    Reading this I keep seeing OOP in there, and data as an object class.

    This is just the OOP crowd trying to not learn SQL and do things their way. It won't replace a full RDBMS. And an RDBMS can scale quite nicely if you know what the hell you're doing.

Slashdot Top Deals

Some people manage by the book, even though they don't know who wrote the book or even what book.

Close