Comments on: Rules of Database App Aging

By: Key/value storage engines « sociomantic labs

Key/value storage engines « sociomantic labs — Tue, 29 Sep 2009 14:14:04 +0000

[...] http://push.cx/2009/rules-of-database-app-aging/ [...]

By: Analysis from the Bottom Up | Improving with Age

Analysis from the Bottom Up | Improving with Age — Thu, 02 Apr 2009 16:31:13 +0000

[...] When I design an application, one of the easier traps to fall into, is the idea that there is only one consumer of the database. This is the luxury of building a brand new web application that has no legacy integration requirements! But, it is a false promise, because it only lasts for a short period of time. Even if you never integrate with another application, the application itself becomes a “legacy” component. Eventually, there will develop a mismatch between the data model and the application. [...]

By: Перевод “Anti-RDBMS: A list of distributed key-value stores” « 13 попугаев

Sun, 22 Feb 2009 16:22:53 +0000

[...] база данных для веба. Статья Rules of Database App Aging некоторым образом объясняет почему [...]

By: Adam Tarnowsky

Adam Tarnowsky — Thu, 29 Jan 2009 17:51:13 +0000

Oh entropy…

By: Graceful Exits » Blog Archive » I’m writing approximately fifteen percent of a book

Sat, 24 Jan 2009 17:56:05 +0000

[...] of discussion of this on the blogosphere which I don’t want to particularly repeat here. Relentless backwards compatibility can be harmful to a living, breathing application, which exists to enable yet constrain a programmer’s [...]

By: Digitalia – Links For Friday 23rd January 2009

Digitalia – Links For Friday 23rd January 2009 — Fri, 23 Jan 2009 18:02:27 +0000

[...] Rules of Database App Aging – Push cx This will be incomprehensible to non developers in the audience, but oh god, this is so painfully, painfully true. (tags: humour programming webdev schema) [...]

By: Anders Nawroth

Anders Nawroth — Tue, 20 Jan 2009 13:48:58 +0000

I wrote Aging databases and relationships in response to this worthwhile post.

By: Damian Cugley

Damian Cugley — Tue, 20 Jan 2009 13:44:10 +0000

You young folk and your text-based HTML templates! You would never get away with an unmatched

 tag if you were using Genshi or some other XML-based templating system... :-)

Gay marriage: the database engineering perspective illustrates these trends well. I would add one other change I have occasionally made, which is replacing a boolean (bit) field with a nullable timestamp.



By: tadhg.com » Blog Archive » Rules of Database App Aging
tadhg.com » Blog Archive » Rules of Database App Aging — Tue, 20 Jan 2009 02:04:45 +0000
[...] came across a blog post about the Rules of Database App Aging today. I’m having another look at my database assumptions at the moment, and the three rules [...]



By: Dean Landolt
Dean Landolt — Mon, 19 Jan 2009 21:22:07 +0000
Then, about a week later, there’s a politician who’s a Democrat but running for re-election as an Independent…
Ahh, Lieberman. I witnessed that blow up the Library of Congress’ data set. He insisted on being called an “Independent Democrat” but party was only 1 char, so they had to use “J”. Of course, they’re running up against their schema-imposed hard limit of 26 parties, and a lot of guard clauses will have to be concocted when that happens.



By: Anti-RDBMS: A list of distributed key-value stores | Richard Jones, Esq.
Anti-RDBMS: A list of distributed key-value stores | Richard Jones, Esq. — Mon, 19 Jan 2009 17:15:31 +0000
[...] curious how the web’s trendiest document database works under the hood. This article on the Rules of Database App Aging goes some way to explaining why document-oriented databases make sense. CouchDB can do full text [...]



By: Peter Harkins
Peter Harkins — Sun, 18 Jan 2009 17:37:20 +0000
Jonathan: Yes and no, sometimes the information for great planning doesn’t exist or isn’t available. The best plan is then to fit the circumstances as you know them and change when they change, which is what’s described above. It only looks like poor planning in hindsight.



By: Pinderkent
Pinderkent — Sun, 18 Jan 2009 03:02:25 +0000
Most real-world relationships are truly many-to-many….
Today I read some very true observations from Peter Harkins about the nature of aging databases. He mentions three such observations in his article, and other readers have contributed several more in the comments for that article, as well as at other s…



By: Jonathan Holland
Jonathan Holland — Sun, 18 Jan 2009 01:29:46 +0000
This sounds more like database aging when your original schema was poorly planned.



By: Peter Harkins
Peter Harkins — Sun, 18 Jan 2009 01:27:40 +0000
Ah, got me there, then.



By: Dave Rolsky
Dave Rolsky — Sat, 17 Jan 2009 20:55:01 +0000
Relations are not relationships. Relations is the logic/math geekspeak for what SQL calls tables (though tables aren’t _quite_ the same as proper relational relations).
The “relational” in relational databases has nothing to do with relationships, rather it’s called relational because the data is stored in relations (tables).



By: Al
Al — Sat, 17 Jan 2009 13:29:49 +0000
We try as best as we can to continually refactor our code and database in step with feature requests. I’ve seen far too many projects where that doesn’t happen at an appropriate pace to changes in an application and virtually every point you listed happens to some extent or another and more.



By: Mark
Mark — Sat, 17 Jan 2009 13:16:28 +0000
Another one:

- enumerations in applications often become user definable, usually resulting in a mess



By: Jason Kester
Jason Kester — Sat, 17 Jan 2009 07:25:29 +0000
One more you missed:
4. Existing fields get “re-purposed”
So the Notes column suddenly has a bunch of State Codes in it, “Select distinct Gender from SiteUser” returns seven rows, and some clever junior dev notices that the TripID column in the Image table doesn’t get used in the case of Outfitters, so really we can just store OutfitterIDs in that column too.  Of course we’ll need to drop that foreign key constraint…



By: Dale
Dale — Fri, 16 Jan 2009 18:29:05 +0000
Good article. Thanks.  And the client can’t really afford to pay you for the real time it takes to avoid these problems so you end up doing a lot of it for free.