Comments on: Denormalizing Databases http://www.thirstymind.org/2007/12/22/denormalizing-databases/ andrew watts' weblog Sun, 04 Oct 2009 20:37:41 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: tmarthal http://www.thirstymind.org/2007/12/22/denormalizing-databases/comment-page-1/#comment-14760 tmarthal Tue, 26 Feb 2008 21:03:39 +0000 http://www.thirstymind.org/2007/12/22/denormalizing-databases/#comment-14760 I think you want a hash of hashes, not a relational database. =( I think you want a hash of hashes, not a relational database. =(

]]> By: Andrew Watts http://www.thirstymind.org/2007/12/22/denormalizing-databases/comment-page-1/#comment-14629 Andrew Watts Sat, 19 Jan 2008 19:57:14 +0000 http://www.thirstymind.org/2007/12/22/denormalizing-databases/#comment-14629 i am not sure where you are going with that line of thought and what do you mean by distributed (ie: distributed app servers sharing a managed db connection, or distributed clients that each have a different db connections or ?). Managing conflicts, i think, is the job of the transaction manager. Obviously you would still need to ensure ACID, but that is the job of the dbms, and I am not sure much changes when going from a normalized schema to a denormalized one. I'll have to think about it some more and do some reading. I am no ORM or DB expert. But the original point was denormalizing improves performance, specifically query performance not update performance. So why not design that way from the start? I've found that most people and customers don't like waiting for transactions, and the max upper limit on any request/response sequence is about 4-5 seconds before the user begins to get agitated and/or gives up and/or starts cursing the app. Along with this, most customers, again in my experience, do more searching for data rather than updating data. So, to date, query performance has been of prime importance for the apps I have worked on. With that being the goal, it seems one should focus on designing a db that will allow you to achieve that goal, rather than designing a normalized schema, just because your college prof or oracle instructor told you the best way to manage a database was normalizing the schema. Yes that may be the best way to manage a database, but ultimately the customer doesn't care how the database is managed, they just want a fast responsive app. i am not sure where you are going with that line of thought and what do you mean by distributed (ie: distributed app servers sharing a managed db connection, or distributed clients that each have a different db connections or ?). Managing conflicts, i think, is the job of the transaction manager. Obviously you would still need to ensure ACID, but that is the job of the dbms, and I am not sure much changes when going from a normalized schema to a denormalized one.

I’ll have to think about it some more and do some reading. I am no ORM or DB expert.

But the original point was denormalizing improves performance, specifically query performance not update performance. So why not design that way from the start?

I’ve found that most people and customers don’t like waiting for transactions, and the max upper limit on any request/response sequence is about 4-5 seconds before the user begins to get agitated and/or gives up and/or starts cursing the app.

Along with this, most customers, again in my experience, do more searching for data rather than updating data.

So, to date, query performance has been of prime importance for the apps I have worked on.

With that being the goal, it seems one should focus on designing a db that will allow you to achieve that goal, rather than designing a normalized schema, just because your college prof or oracle instructor told you the best way to manage a database was normalizing the schema. Yes that may be the best way to manage a database, but ultimately the customer doesn’t care how the database is managed, they just want a fast responsive app.

]]> By: Matthew http://www.thirstymind.org/2007/12/22/denormalizing-databases/comment-page-1/#comment-14622 Matthew Fri, 18 Jan 2008 06:48:22 +0000 http://www.thirstymind.org/2007/12/22/denormalizing-databases/#comment-14622 Because now all your data must be added, updated, and deleted together. If you have a distributed application and one client updates one object then you must perform conflict detection and management across the entire row, even if data isn't closely related, and you'll probably end up impacting every client on the system. Because now all your data must be added, updated, and deleted together. If you have a distributed application and one client updates one object then you must perform conflict detection and management across the entire row, even if data isn’t closely related, and you’ll probably end up impacting every client on the system.

]]> By: Andrew Watts http://www.thirstymind.org/2007/12/22/denormalizing-databases/comment-page-1/#comment-14620 Andrew Watts Fri, 18 Jan 2008 01:25:07 +0000 http://www.thirstymind.org/2007/12/22/denormalizing-databases/#comment-14620 why not? why not?

]]> By: Matthew http://www.thirstymind.org/2007/12/22/denormalizing-databases/comment-page-1/#comment-14617 Matthew Thu, 17 Jan 2008 17:53:31 +0000 http://www.thirstymind.org/2007/12/22/denormalizing-databases/#comment-14617 I don't think it would be very clean mapping the data into objects if it all came from one table. I don’t think it would be very clean mapping the data into objects if it all came from one table.

]]>