Re: InnoDB vs MyISAM using MySQL for a Social Networking Website
Posted: Thu Dec 18, 2008 3:31 pm
Agile designInteresting - what's the new-school DB design
I see a difference between error handling and testing. I test my application code, I don't use it (application code) to test my database logic.Yeah, some call this "testing"
The unfortunate truth is that due to security concerns validation is repeated on both client side and server side. But you're talking about something different. In applications where the UI and business logic interact directly (same language), this logic could easily be reused (and therefore less chance for mistakes). Not so when it's inside the database.1. Think of client-side filtering/validation and server-side filtering/validation
I didn't say that so much of the logic changes, but nothing is sacred. I embrace an open and agile design style - I constantly refactor my code-base to best suit the changing requirements (requirements are never frozen. another unfortunate truth).2. If you change so much of the logic then it's a bad design from the very beginning or user-requirements have not been collected properly and completely. In both cases refactoring would rarely work - you will need to redesign it and rewrite it.
In order to be able to constantly refactor the code, I need the database to be flexible as well. For me this means, that if I use foreign keys, I will probably implement them near the end of the development cycle.
What I meant is that logical errors could be induced anywhere, whether the logic is in the database or the application. So you can't rely on database logic as foolproof.Also, a SQL schema create script file would usually contain < 1000 lines (with some SP defined < 2000-3000). Constraints definition lines number will be much less - lets say 10%. It is far far away from the number of code lines used in the application. So... calculate the possibility of errors.
In the end I guess our different approaches result from different experiences with different projects and from a different development style.