On 1/30/07, Ala'a Ibrahim <[EMAIL PROTECTED]> wrote: > > well, it's really a tough question, it's like PHP promotes unstructured > code ... > From my point of view, it's the programmers choice. > you can put a data access layer in your code to enforce constraints on > your transactions, or if you insist, you can use the InnoDB engine, also > MySQL 5 supports triggers, you can use them to apply your constraints, or > you can dumb MySQL and try to find another DBMS. > it depends on what are your needs, and what suits your project more. i > don't think a language or a DBMS would promote anything, they are just tools > to make your life easier. > also db design is not just about constraints, a more important part of it > is where everything goes, how my queries are going to be faster, and what > DBMS you should use. > well MySQL gives you a variety of options, one of them should be default, > and that one is myisam, but there is a list of options, depends on your > need. > > On 1/30/07, Al-Faisal El-Dajani <[EMAIL PROTECTED]> wrote: > > > > Hello guys, > > > > I was just thinking, does the use of MySQL DB engine promote bad DB > > design decisions? > > > > I am a huge fan of enforcing constraints wherever possible, and one of > > the most important constraints in DB design is the foreign key constraint. > > Since the default transaction manager in MySQL is MyISAM -which doesn't > > enforce those constraints, does MySQL promote bad design and development > > habits? > > > > Just a thought... > > -- > > Al-Faisal El-Dajani > > Phone: +962-7-77 799 781 > > P.O Box: 140056 > > 11814 Amman, Jordan > > > > > > > -- > Ala'a A. Ibrahim > http://alaa-ibrahim.com/guru > >
I agree with what Ala'a said. When I was in PHP Vikinger a year ago, Rasmus said there's the "MySQL way" which is basicly what some people refer to as bad design habits. On the other hand, the biggest most succesful PHP applications don't enforce anything on the DB level. I'm a fan (well, most of the time) of application level enforcements. I just find it terrible to handle errors and display them back to the user when data is not valid, and that invalidity is coming from a DB constraint. The point from doing DB constrains in my humble opinion (IMHO), is two things: 1- centralized data constraint (one place to know if data is valid or not) 2- Simplicty, as you always know where to check, instead of digging up a pile of source code The first point can be acheived by good application design, if the application is well designed, I think it should have a central place where all database interaction happens, and I'm not talking about sending SQL. Even loading data from database to the application, a very good example which might be a bit overdesigned is ORM (Object Record Mapping). You have a set of classes that handle mapping records in the database to objects in the application which is also referred to as Data Access Objects (DAO). You can simply enforce the constraints on the setters (mutators) of that class. I like the simplicity part in DB constraints, you don't need to dig in the code to know where everything is defined, that's a big bonus, but it can be limiting sometimes. What if data is validated against a 3rd party service that uses SOAP as an interface? How would you define such a constraint in the database? I think it would be rather bloat (if it's possible, I think some RDBMS can do constraints via external shell commands or whatever, which gives them ultimate capabilities to talk to anything you want). Then again, it's up to the scenario. There's never right or wrong. There's always a trade off. - Ammar --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Jordan PHP Users Group" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/JoPHP http://Jolug.org/ -~----------~----~----~----~------~----~------~--~---
