|
There's no good idea or pattern that some team, somewhere, can't warp to create a bad outcome. Generally speaking there are lots of well-established best-practices, that are best in most contexts, but which fall over in other contexts. Knowing what to do where is part of the intangibleness that separates the great from the good from the competent. So some things are good to defer. -if- this product works, we -may- need to scale, so let's choose a database, and design, that allows for multiple servers. Picking say Postgres over SQLite. Other times saying "this is just a proof of concept, do it quick in SQLite". Is our API gonna be XML or JSON? Not sure, could go either way. Let's design so that part can be trivially replaced. With data design especially, IMO, it's worth -planning- for success. Starting with uuid will end up fine for 99% of the tables which will have "not many records". When we identify that 1%, which are growing by millions of records a minute, we can adjust for that table as desired. [On a side note, regarding clustering, it seems some people aren't aware that the primary key and clustered key don't have to be the same.] |