Slashdot Mirror

Actually you would not use a DB for that.
The prime mistake of plenty of such endeavors is that they use a DB ...

If you want to call it a DB, then yo use a "main memory DB". Obviously you have to shard it by solar system or clusters of some systems. But you would keep all state in memory. Only write stuff to disk to be able to recover from a crash.

E.g. http://www.prevayler.org/

I'm sure you will need this technology to back up Duke Nukem Forever, since the Holographic RAM IBM was supposed to release in 2003 core dumps to tape.

I was always interested in the Prevayler methodology. The concept is that the database is one big transaction log, with occasional full rewrites to speed up restarts. It's a neat idea, and seems to work rather well in practice. (Though the API is unnecessarily PAINFUL.)

Traditionally, however, a classic database is mated with a transaction log. The transaction log can be rerun to get the state of the database at any point in time. That way if the database is modified or goes kaput, the transaction log can be used to verify or rebuild the data.

You say "if you take an approach like Prevayler you can still have reliability and transactional integrity."

Prevayler does not provide ACID transactions. Saying "you don't need rollback or undo" is all well and good, but you can't call it a transaction. It's not atomic, and it's not consistent.

So if you use Prevayler, do you have "reliability" and "transactional integrity"? No. It's something you have to code yourself. Among other things, you have to make sure no code in a transaction ever throws a RuntimeException: http://www.prevayler.org/wiki.jsp?topic=RollbackIs Needless. So your statement is incorrect.

Before that talk I never new you could run entire systems directly from RAM. Wild.

Yes, it's very cool. Done right, response times are dumbfounding. And if you take an approach like Prevayler you can still have reliability and transactional integrity.

All the hardwork for sorting etc are done already by Oracle inside their DB. [...] Then came JAVA which removed even the need to do memory managment.

The problem isn't those tools; the problem is that some mediocre developers stop thinking except in terms of those tools. You mainly see this in "enterprise" shops. Most of them only think in terms of turning a problem into SQL requests. That's what makes back-to-basics approaches like Prevayler seem heretical in some quarters.

I'm sure Oracle encourages this, as I have personally seen them make millions of dollars because some programmers for a major corporation couldn't deal with any other paradigm.

But if you stay out of the "enterprise" IT market, there's plenty of innovation going on. Find somebody doing games, or consumer apps, or high-end web stuff, or anything where buying one copy of oracle per installation doesn't make sense. You know that Google isn't powered by Oracle, and they're vacuuming up smart people.

Eventually, the enterprise swamp will get sorted out. People who actually can do CS will keep automating the monkey work. The legions of corporate drone programmers will hopefully do interesting stuff, but probably just find another way to suck on the corporate teat.

I didn't RTFA but for my needs

Or the summary

mySQL suits me quite well.

That's nice. It won't handle a multi-terabyte database, though. That's the domain of Terabase, Oracle, and (blech) DB2. It's also what the article is about.

The power of PHP and mySQL is all I need.

And a moped is all you need to get to work. If you want to haul 300 metric tons of rock from point A to point B, you need a dump truck. Again, that's what this article is about.

Back on topic, this entire article is mostly speculative for the moment. A lot of excellent work has been done in OODB and XMLDB designs, but no singular design has yet emerged to solve all our woes. For example, I love the Prevayler concept. It solves a lot of problems, lowers data access times, and provides for complete data security. It also isn't usable or scalable without a lot more design work.

The future will hold some very interesting things, but for now we'll have to keep inventing until we come up with a consolidated solution.

[misc drivel] Read more at:
http://www.prevayler.org/

Oh my dear god. You've never actually used Prevayler have you? Prevayler isn't nearly as useful on actual data problems as Prevayler's worshippers would have you believe.

I know this because I tried to use it. If you'd ever tried to use it, you'd know how unbelievably poorly it performed when attempting to implement real world queries. You have to implement every query in Java, and Java is a particularly poor implementation choice for creating complex queries.

What if I said that this can be as fast as 8000 times faster than Oracle?

This "performance comparison" that the Prevayler group trots out is particularly funny as their test uses a single ArrayList of objects as in-memory "storage" and then "queries" it by index. Not exactly a realistic problem. Try a query across four classes with a few million instances of each class and you'll quickly discover what relational databases are good for.

Regards,
Ross

Picture this... memory nowdays is a hell lot cheaper than a full Oracle Licence. So, instead of investing on a DBMS why not buy massive quantities of ECC memory and keep all instances of your data in-memory for near instant access?

Crazy idea, huh? What if I said that this can be as fast as 8000 times faster than Oracle? And 3000 times faster than MySQL!

Crash recovery? No big deal, keep a serialized version of your in-memory-objects, and a transaction log and you're set!

Read more at:
http://www.prevayler.org/

When all the game data fits in RAM, you can do it like Age Of Empires or Starcraft do it: http://www.prevayler.org/wiki.jsp?topic=MajorCompa niesUsingPrevalence When you can't fit all game data in RAM, you better resort to an OODBMS such as http://www.db4o.com/ See you, Klaus.

You mean object prevalence like in Prevayler? See also here for a general presentation (intro here: Object Prevalence in C++).

What is the purpose of embedding SQL?

Why would I handicap myself like that, when I don't need ad-hoc reporting and when no other system is going to share my data?

Why wouldn't I just use native Java objects?

See you, Klaus.
http://www.db4o.com/ - The Leading Open Source Object Database
http://www.prevayler.org/ - Do You Still Use a Database?

Sounds very much like prevayler. http://www.prevayler.org/ DISCLAIMER: I haven't tried it but in some former /. one guy raved about it.

Many of my favorites have already been mentioned: junit, jdom, xstream, log4j, and many things from Jakarta Commons.

The other things I use regularly are HttpUnit, a virtual web client and Prevayler, a simple Java persistence framework.

> Plus the extra memory addressing does have it's uses...you'll see.

Prevayler comes to mind.

The relational model supports any kind of data structure ever invented, but it's true that you sometimes want to store opaque blobs of data such as graphics or XML documents, and most databases, including Derby, supports that as well.

Perhaps you should look at an object-relational mapping layer such as Hibernate or TJDO, or a hybrid object database such as Prevayler.

But what are these alternatives you mention that are so much better suited for every possible scenario?

There is, of course, no tool that meets the needs of every possible scenario. Instead, there are tools that meet the needs of common scenarios. Most of what MySQL is being (improperly) used for could be easily replaced with PostgreSQL. Postgres offer similar performance, but takes a minor hit for data integrity. As a bonus, you gain sub-selects, stored procedures, SQL-92 compliance, and other features of a "real" SQL database.

MySQL is quite decent for something like a blog, but why even bother with a complete server in those cases? An embedded database such as Berkeley DB or HSQL (formerly Hypersonic) would provide better performance and would get rid of security issues inherent in running a complete database server.

In still other instances, SQL databases are misused for large object data storage. In many of these instances, an Object Database such as ObjectStore (or your favorite open source choice of the 1000+ options) will provide better performance, without sacrificing much in the way of database management. (Standard database management tools are usually insufficient for dealing with databases containing large amounts of LOBs.)

Basically, the choice in database and database technology should be carefully weighed against the application instead of saying "I know SQL and MySQL is 1337!"

Some other database options include:

DaffodilDB
SAP DB
FireBird DB
Cloudscape (Soon to be open source)
Xindice (XML Database)
ObjectDB
DB4O
Prevayler

However, for my Java consulting business, Prevalyer is definitely my new "secret weapon". With a little care, it is easy to set up your POJO classes so that you can add class attributes without breaking your persistent Prevayler object store. Using Prevayler reduces development time. Good stuff.

It's the startup time.

I have no complaint about the speed of a Java application once it is up and running. The only problem I have is that the runtime takes so long to heave its vast bulk into memory and fiddle with stuff before the app. gets control.

Will not be a problem for long. Just wait until we trade our hard drives for 500GB non-volatile RAM. Everything will start up in zero time and we will all run Prevayler. As early as in 2004.

How about something like prevayler. I haven't actually used it yet, just have it on my radar as something to check out later.

• The first is the object interface itself. If the object interface doesn't have a way to change something, then there's no way to break it externally.
• The second is the internal object code. It should be written in such a way that the integrity requirements are clear. A developer mucking around in the object's code should be able to tell what the important bits are.
• The third is the unit tests. Not only will they document the purpose and nature of the object, but they will also prevent a careless developer from breaking something important.

You're correct, of course. The principles should be simple. They should be fairly compact, and like all principles, they should come from the well of experience. The principles for good OO design are fairly simple:

Don't Repeat Yourself: knowledge should be represented only once in the system.

Tell, don't ask.

Classify objects in your systems by the messages they respond to, and the responsibilities they hold.

An object should only call features of: a: an object passed into it as an argument, b: an object it creates, or c: itself (I think this is the correct form of the "Law of Demeter")

Prefer short methods.

Apply design patterns according to the problems they are intended to solve.

When using design patterns, find the pattern that sets the context, this will help you identify other companion patterns that typically apply to the problem (or related problems).

Design your code to be tested, or better, write test code to help flush out the design.

Keep a nostril open for code smells, use refactorings and tests to fix the problem.

...

Always remember these are principles and not rules.

Now explaining those principles with code and narrative will fill up 700 pages if you give the whole history of how they came to be. Or you can just visit the pragmatic programmers' web site and read a bit less than 700 pages.

I also agree that the typical notion of encapsulation doesn't necessarily protect the data. When most people think of encapsulating they think of putting a barrier of functions between a data consumer and the provider (I was revolted when I first saw this in Java, I think C# and Delphi do this better with the first class notion of property). But the other meaning for encapsulation is "to embody" the data. I think that ends up being a more powerful concept when properly applied than publishing getters and setters for attirbutes that might as well be public. The idea that some other object must consume (get) the data is the first warning sign that the design is deviating from the OO way of thinking (OK, OK, paradigm, there I typed it again). When an object embodies the data, encapsulation can, in fact, protect it. But I was actually thinking that polymorphism provides a better way to ensure consistent handling of data in an OO system.

Ironically, MDA is closer to your concept of TOP than OOP is, as MDA is metadata-intensive and oriented to the creation of purpose-built syntaxes (modeling languages), although it is not specific to relational database access.

You might find this flabergasting, but I'm tempted to believe that relational databases aren't all that necessary any more. Most modern relational database hold nearly all of their data in memory. That's the only way they can achieve the performance they do. Take Oracle databases for example. In my shop the Oracle instances we run typically hold 98% of their data in memory (we have big Solaris boxen). So why not use some sort of memory snapshot system like Prevayler? The answer, of course, is that too many developers find this scary. The other argument against this is 'reporting tools.'

No, I'm not suggesting we all throw out our relational databases. But I do think there is life beyond relational data.

Also, I didn't build an example of a bad procedural system for this post. I apologize. As you know, that takes a lot of effort. Instead, as a consolation, have a look here: http://www.nakedobjects.org/section6.html Their discussion is actually about the pitfalls of task-oriented UI design, but their arguments apply to this discussion. Task-oriented UI design typically goes hand-in-hand with transaction script architecture and falls prey to the same issues (I'll even add an 'IMHO' to that). I think you'll like their spaghetti diagram a bit of the way down the page.

Thanks for the response, and the discussion.

Michael Murphree

Enumorators? Reflection?

I'm only a beginner in C# and Java, but I know both have reflection, and the proposed Java 1.5 has enums. Kudos to C# for having them first :-), but Java 1.5 has them better, as first-class objects.

Also .net/IIS is a better platform for webdevelopment.

Better for whom? Why? Doesn't it have the severe shortcoming of platform lockdown?

I can write a c#.net app in 1/4th the code of a java one. Go take a look at Microsoft's petshop program if you do not believe me.

I can write an assembly app in 1/4 the code of a Python one. Assuming, of course, that the Python app wasn't written for small code size... The simile is very accurate; Sun didn't write their petshop for small size.

The Java Petshop reimplementation here spanks both Sun's and Microsoft's petshop in terms of size, and pretty clearly demonstrates that both languages could do better.

BTW, I absolutely love C# -- from what I've done with it so far. My only complaint is that its support is at best halfhearted for other platforms, and I will not allow my work to be tied down to one platform. This is the only thing that kept me from learning K (well, K is portable, the only problem is that it's only available from one vendor, Kx systems). Anyhow, I think C#'s bytecode is far beyond anything Sun's ever going to do with Java.

ALso WIndows2k3 is as stable as Linux now. NT4 is old. The situation has improved dramatically. I have never even seen a blue screen on windows2k yet!

I agree with all of that, but it's not enough. I have seen blue screens and system crashes on 2000 and XP (XP far, FAR FAR more often than 2000). But then I've seen system crashes on Linux, so I'm not just complaining about MS ;-).

-Billy

My point here is that your accessor logic (so-called middleware) is what manifests the "foreign" relationship and if that's screwed then your app just doesn't work.

Well, there are two ways of looking at the typical system. Take a web application as an example: Either a) a database is where good objects go to rest when you don't need them, or b) your code is basically an engine for transforming HTTP requests into SQL statements, and then transforming SQL result sets into HTML.

I think you and I are in the first group. The database-centric approach is popular, but I think it is pretty limited, and it introduces too much design inertia. These days I just write my objects in code, and then use an O/R mapper like Hibernate to generate my SQL. If, that is, I use a database at all. Those who can't imagine life without databases should contemplate Google's architecture. Or take a look at Prevayler, a radically different way to build apps.

You've either got the middleware right or not.

Well, here I'd disagree. If referential integrity checks in the database are pretty cheap, I don't see anything wrong with a belt-and-suspenders approach. Even with extensive unit testing and pair programming, I can't so far get my bug rate much below one bug per month. If the database can catch some of those bugs sooner, I'm willing to trade a smidgen of performance.

Of course, as I'm writing this, it occurs to me that databases aren't so great for expressing all the constraints on the data anyhow; if I really want a mechanism for double-checking persistent data, I should just put it in the persistence layer. That would allow me to use the same mechanism on all data, persistent or not.

Ok! You've convinced me. Foreign key constraints are the wrong solution to the problem.

The in-memory master behaviour described in the paper ressembles a lot the Prevayler software.

Cheers

One thing I remember reading is that you can use anything you like to query your objects, as long as it understands objects efficiently. One answer is to use Java, or if you like you can use XPath or XQuery as suggested here.

Cheers

A quick search on the wiki showed no hits for the word 'report'.

Did you try clicking on "Find Page", and typing in "report" (sans-quotes) in the "Search by topic content" field? I found this pretty easily:

Creating Reports With Prevayler

Yeah, seriously, WTF is this shit?

Summary:
"Okay, but it's not a SQL query vs. SQL query comparison."
"Well see, we could write a query in Prevayler, but you can't test MySQL without a SQL query. (cute winky face!)"
"Okay, so write a SQL implementation for Prevayler, then do a SQL query vs. SQL query comparison."
"You need to think outside the box, man. Anyways, the test is fine, because it was done on different systems."

I mean, WTF?

Yeah, seriously, WTF is this shit?

Summary:
"Okay, but it's not a SQL query vs. SQL query comparison."
"Well see, we could write a query in Prevayler, but you can't test MySQL without a SQL query. (cute winky face!)"
"Okay, so write a SQL implementation for Prevayler, then do a SQL query vs. SQL query comparison."
"You need to think outside the box, man. Anyways, the test is fine, because it was done on different systems."

I mean, WTF?

From the Wiki:

Prevalent Hypothesis:
That there is enough RAM to hold all business objects in your system.

IMO, this hypothesis doesn't hold water for 99% of business applications. Prevalent proposes that even if this hypothesis doesn't hold today, it might soon hold true because of breakthroughs in memory technology. But historically these types of ideas are flawed, as the real world has clearly shown that memory and disk needs will grow even faster than our ability to use those resources.

Sure I can take a 1998 application and run it with breakthrough performance by caching the whole application in memory. But I don't want a 1998 application, I want a 2003/2004 application. Do you think that the entire Slashdot comment database would fit into a couple of gigs of memory? How about the enite customer database for an average enterprise?

Frankly, if my database is so small that it fits into memory then I probably don't have performance as a primary concern anyway. Plus, do I really want to subject my entire database to constant mark and sweep garbage collection if performance is an issue?

--
ogren
.no sig

In the prevalent design, every transaction is represented as a serializable object which is atomically written to the queue (a simple log file) and processed by the system.

Zero bugs. Ever.

No one has yet found a bug in Prevayler in a Production release. Who will be the first?

link.

I didn't know people still made such bold assertions past the dot-com era.

read the FAQ

Does Prevalence Only Work In Java.

No.

You can use any language for which you are able to find or build a serialization mechanism...

These hoax-like results are obtained even with the Oracle and MySQL databases fully cached in RAM and on the same physical machine as the test VM.

• have enough RAM to hold all your business objects and
• only need to access your data from Java.

Their jingoism is absurd.

"We have some features that are better than relational databases. RELATIONAL DATABASES SHOULD NEVER BE USED AGAIN."

In their wiki, "When Should I Not Use Prevalence" lists three things:
When you do not know how to program.
When you cannot afford enough RAM to contain all your Business Objects.
When you cannot find a Java Virtual Machine that is robust enough.

That's obviously the stupidest thing ever. How about, "When I don't have the time and money to connect all my company's SQL DB stuff to your java stuff." Obviously my scenario encompasses a whole lot more users than their three, and perhaps explains why no one is using their product.

What assholes.

here

Or use Prevayler so you dont need a dbms anymore.

These awaful pieces of flawed technology will be obsolete and thought as one of the deformities of the malformed "information age" once things such as object prevalence get into mainstream, which will happen once the amount of main memory on computers become able to store the whole data in hand.

The .NET Framework has a SLIGHTLY smaller footprint than the latest version of Java (46.5 vs 47.3 on my workstation). And it does more stuff -- a lot of the add-on packages for Java, including all of their J2EE crap, parellels what's already in the Framework. Not that it matters...including the framework on an install CD is trivial, and most Windows Update and XP users have it already.

You said it yourself. You can't really compare size like that since there is more to .NET than just the libraries and the VM. .NET uses a huge amount of bread&butter stuff in the Windows libraries, something which obviously can't be used by Java. At least not in the same way, since Java has to work on more than one platform.

.NET does NOT integrate the web into windows applications. .NET allows users to create web apps in much the same interface as standard windows forms, using a system called WebForms.

True, but it does integrate .NET into the web. It makes it very easy to build applications with much more "intelligence" on the client side, similar to building a XUL application using Mozilla.

The downside (or advantage, if you're Microsoft) is that you will only get these "rich" client experiences when running Explorer, preferably on Windows. But that's the whole point. Lock-in by pretending to be open, it's brilliant.

It also allows regular ASP pages to be compiled into faster versions a la JSP/Servlets.

True again, but they are still slower than JSP's on fast app servers, for example Orion. (disclaimer: I don't have the latest benchmarks so things may have changed).

What's cool about .NET is that the IDE supports all sorts of really useful data transformation and reporting mechanisms using SQL/XML/etc built right in...no rolling your own data access methods (though I end up doing it anyway).

These things has been available in Java IDE's/libraries/toolkits for longer than I care to remember. I believe it started with Sun's JavaBlend (which agreeably wasn't very good, but a lot has happened in the 6 or so years since it came out).

Today we have several frameworks, suitable for different needs. For example Hibernate, JDO, or, if you simply want a fast persistance layer: Prevayler. There are more, of course.

Also note that the the JDO specification allows different vedors to plug in different implementations so you're not relying on a single vendor. This goes for pretty much all of the J2EE specifications as well. I'll take that over Microsofts solutions any day.

.NET is better than Java for apps that will always be used on a Windows PC, because: - It has a much faster graphics interface, while maintaining a robust graphics toolkit.

And how do you know that your apps will always be used on a Windows PC? Do you have a magic crystal ball that can see into the future? Do you really want your apps to be limited to Windows only? Also, with the latest versions of Java, the speed difference (for well written applications, mind you) is neglible. Take a look at IDEA for a good example of a very efficient Swing application. And if you really believe you need native widgets, take a look at SWT, which Ecplise is built upon. But it's a pain to program in, and it's only really cross-platform on Windows. All other platforms suffer from the same problems as Swing apps do.

It has a better messaging mechanism (Events/Delegates are a GODSEND and are the sin

The purpose of application servers is to have a canned infrastructure capable of handling these problems well. There are many other plumbing considerations that application servers keep track of...

Prevayler is a system where your java objects persist as objects in RAM. No need for a database at all, retains the goodness of OO design.

Their bold claim: "Queries with Prevayler are more than 3000 times faster than querying MySQL through JDBC."

You manipulate them via serialised commands which are logged and you take a snapshot every day or so. If there's an accident, you reload the last snapshot and replay the command log until you catch up and then you're off again.

With everything in RAM, why not create true object servers, rather than distorting and maiming our object models by breaking encapsulation & imposing database layout restrictions?

http://www.prevayler.org

...But such a condition (DB in RAM) will make his product pretty much obsolete.
The Prevayler Project is a RAM-only Java persistence project that works and is so simple not a single bug has been found in the production release.
3000 times faster that MySQL (9000 times faster than Oracle) even with the database in caches entirely in RAM simply because of the JDBC overhead that is eliminated .
The only sticking points I've seen are:
1. Normal PC's boards generally will only take 1GB of RAM. Sure there are thos expensive Sun machines...
2. Querying objects in an efficient manner.
3. Others, but I've gotta take a dump real bad...

How much does the software trust the underlying OS and hardware?

Prevayler does the proper paranoid thing, syncing after every write.

If you want less paranoia, you could easily do that; it's a one-line code change. Or you could just ask your operating system to do it.

If that ends up being a speed issue, then there are plenty of ways to improve IO. But really, putting bytes on the end of an open file is pretty fast these days, so I doubt many will hit this bottleneck in practice.

What if your command is slow? Safe would be to serialize all commands, but I doubt that's what they do based on the performance. It appears they just don't acknowledge the issue. This means that the log written to disk might generate different final snapshots depending on the relative execution time between two different reconstructions.

Prevayler applies commands in strict linear order. Thus it's completely deterministic, and therefore most of your worries aren't an issue.

I think the only remaining one is long transactions. Since Command objects are executed one at a time, a slow command will cause writes to block. The solution: Don't use Prevayler Commands for long transactions. If you need to do something that takes a while, then you should do that first, build up the Command, and then submit that for execution.

So again, use the right tool for the job, and don't buy into their ~"you won't ever need a dbms again"~ marketing hype.

Until you know what this tool is, you'll have a hard time telling what it's good for. Perhaps you could start by reading the FAQ, where a lot of your issues are covered.

Excellent summary -- I see the problem. The other articles on the subject are written in a much more usable manner. Let me cover the ACID test, though.

1. Atomicity is implemented at the method-call level; there's no notion of a transaction (even a read transaction) that can be open while others are open too. The exception to that, of course, is if you write methods that read values from the business objects WITHOUT using doing it inside a Serializable subclass, in which case you've lost your atomicity anyway.

Commands are atomic (note the technical term "command"). It's possible to get around this; multiple read commands can be permitted at the same time, and don't even have to be journalled, but that's an optimization that's explored elsewhere in the OP literature (and has obvious shortcomings in that you give up Isolation).

2. It appears that there is no declarative data consistency checking; that's left up to the individual programmer accessing the Java objects directly.

Yes, because OP isn't declarative. A system can be added to any language you desire to give you preconditions, postconditions, and invariants; this is an old problem.

3. It appears that there is no transaction isolation; any code can read from the business objects directly.

Not really. Commands provide isolation; you're not supposed to access business objects outside of the context of a command.

4. There is a journaling mechanism that does provide durability.

Right.

Seriously, I agree with you on C; otherwise, prevalence seems to handle AID, and consistency can be handled with differing ease depending on your design.

-Billy

Java, for example, has handy built-in stuff for indexing, joins, filtering, and multi-user contention management.

In that case, keeping everything in RAM in Java objects is hundreds of times faster than fetching from a database.

• One problem is that rectangular tables don't map particularly well to hierachies of objects. This results in either distorted OO models or database layouts that look weird to DBAs (and are therefore hard to optimize).
• Another big problem is that they encourage procedural thinking. There is an awful lot of Java code out there that isn't in any sense object oriented; it is so procedural that it might as well be written in COBOL.
• A third is that they encourage leakage between layers. I don't know how much code I've seen where SQL is scattered fucking everywhere, rather than isolated to a persistence tier. Sure, you can say that programmers shouldn't do that, but when faced with a deadline, an awful lot of developers will cough up some SQL hairball rather than fixing the underlying design issue.
• A fourth is that since the schema duplicates information in your code, this acts as a brake on refactoring. If you use a Martin Fowler's tricks for keeping the database in sync (or if you use a good O/R mapper) you can survive this, but it's still a pain.
• And a fifth is that once the database exists, no matter how much the original designers warn against it, people start using the database as an integration layer. Suddenly 14 different apps are munging the same data, making it impossible to change the schema, and nearly as hard to track down a bug. The whole point of OO programming is that data should always be wrapped by the code that goes with it.
• But my biggest gripe about them is that for 90% of the OO apps out there, an SQL engine just isn't necessary, and only serves to slow things at development and again at runtime.
  

• One problem is that rectangular tables don't map particularly well to hierachies of objects. This results in either distorted OO models or database layouts that look weird to DBAs (and are therefore hard to optimize).
• Another big problem is that they encourage procedural thinking. There is an awful lot of Java code out there that isn't in any sense object oriented; it is so procedural that it might as well be written in COBOL.
• A third is that they encourage leakage between layers. I don't know how much code I've seen where SQL is scattered fucking everywhere, rather than isolated to a persistence tier. Sure, you can say that programmers shouldn't do that, but when faced with a deadline, an awful lot of developers will cough up some SQL hairball rather than fixing the underlying design issue.
• A fourth is that since the schema duplicates information in your code, this acts as a brake on refactoring. If you use a Martin Fowler's tricks for keeping the database in sync (or if you use a good O/R mapper) you can survive this, but it's still a pain.
• And a fifth is that once the database exists, no matter how much the original designers warn against it, people start using the database as an integration layer. Suddenly 14 different apps are munging the same data, making it impossible to change the schema, and nearly as hard to track down a bug. The whole point of OO programming is that data should always be wrapped by the code that goes with it.
• But my biggest gripe about them is that for 90% of the OO apps out there, an SQL engine just isn't necessary, and only serves to slow things at development and again at runtime.