March 31, 2017 at 11:07 pm
Comments posted to this topic are about the item The Ideal Agile Database
Best wishes,
Phil Factor
April 3, 2017 at 6:47 am
Long ago my company had many passionate discussions about 'what is a database?' The best definition I got out of it all is that a database is any place you store and get data: Digital file(s), paper file(s), matchbook cover or what ever. What people really want is a Database Management System (DBMS) that has whatever features that are really needed, from access control and monitoring to ACID or back up and recovery, etc. The change in vocabulary shortened and de-escalated discussions to focus on the requirements of the needed DBMS and which product would best meet them.
April 3, 2017 at 7:10 am
Yeah. Painful, these discussions. Particularly after a good lunch. A lot of people think that anything bigger than an excel spreadsheet must be a database. I once made people correctly answer five simple questions about what a database was before I'd talk databases with them. After all, you'd need to at least know how many wheels a car should have before you buy one. It made for quieter afternoons.
Best wishes,
Phil Factor
April 3, 2017 at 9:24 am
Rather than attempting to shoe-horn all the project requirements into one database, in many cases a more agile (or "ideal") solution would be two dissimilar but complementary database platforms working in conjunction. For example the product catalog, session state, and shopping cart features of an eCommerce application could be better implemented in a non-relational JSON based database like MongoDB, while the sales, accounting, and other operational aspects of the business certainly belong in an RDMS like SQL Server.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 3, 2017 at 10:22 am
Some would consider Excel a database. It certain is a data repository but not a DBMS. Perhaps they are technically correct but when most people use the term database it is not what they mean. They mean a DBMS. What features that DBMS has is a critical part of the requirements. Editorial is spot on in highlighting that so many features are just expected to exist.
My favourite missing database feature anecdote is the BitCoin exchange flaw (and hack and heist) due to the lack of ACID properties. It was not a flaw in the NoSQL database. It was a flaw in the use of the NoSQL database.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 3, 2017 at 11:47 am
Phabulous advice Phil. When gathering requirements you should never specify a database, you shouldn't even conceptualize it. Use persistence instead. Once you have your requirements, as Phil said, your normal relational solution will nicely fit 90% of the cases. The 10% can get complex, again as Phil said, maybe requiring persistence on the client or some hybrid solution. In any case, focus on requirements and implement the correct solution.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply