"Diez B. Roggisch" <[EMAIL PROTECTED]> writes: > - you lose database vendor independence - on a much larger scale than with > the comparably small differences between e.g. postgres and oracle on the > pure SQL level - which are handled by ORMs anyway.
If you're optimizing your project to squeeze the most out of it then you won't design based on database independence. Neither on language independence as well. And, by the way, do you *really* believe that there exist database independence? You'll end up with several corn cases and design for a lower common set of "features". Using what each database allows you to use will get you more performance. It is all a matter of what is worth to your pockets and to your client's pockets. > - having developers understand two programming languages If you have no idea how SQL work you won't get there with an ORM. See what you have to do with SQL Alchemy and with SQL Object. Even the terminology on methods is targeted towards the database lingo. > - the database languages are severely limited in what contextual information > they can access, as there is no in-process data. Thus you end up storing > > all kind of volatile data in there, too It all depends on design. You should have all data needed to reconstruct the input otherwise you'll end up with just data and no information inside the database. If you can recover things, then you have all the context you need. > - even though it might be a question of project leadership, triggers and the > > like tend to be edited in-place often, and are sometimes not subject to > version control at the level they should be. It is a matter of discipline. Nothing prevents your small typo fixes or parameterization to being done on the production environment without ever returning to the version control system. Here every maintenance done on the database with SQL code is considered part of the app and is versioned as well. > - how do you test this, without sqlite supporting the same trigger languages > as e.g. oracle or postgres? This heavily complicates testing. If you're deploying on Oracle you can't test on SQLite. Period. You have to test on the same target you'll be deploying. There are too many differences from one database to the other to make testing in one of them the answer to solve problems in all of them. > - surprises everywhere - the nature of triggers makes it hard to grasp _what_ > actually happens. Don't get me wrong, I'm a friend of magic as well, but > in python I can at least follow stuff around in my editor - who knows what > runs in the database? Who knows what runs on each module you use? ;-) If you're using modules as blackboxes nothing prevents you from using the database as a blackbox as well. For me it *is* part of the code. You don't need to be the one guy that wrote all the application to be able to read some code or at least some comments. Also, documentation *IS* mandatory in every aspect of your project, why would you leave your database code undocumented? > - smearing application logic over several layers without any _need_ to do > so makes understanding the app considerably more difficult. Duplicating logic in several applications and different programming languages make it very hard to fix bugs. So, pick your side on this last one :-) > The applications I've seen that depended on triggers and the like all had one > major flaw IMHO: they lacked a proper three-tier abstraction or at least a > core library containing the app-logic was missing - and instead communicated > over the DB. Which meant that they had different application parts that > awfully often went out-of-sync regarding of what they expected to be in the > DB, and in what form - with the result that triggers were brought into the > game to patch over those gaps in logic. Triggers doesn't solve design problems. You still have to design the application in all layers. You do that in your views, you do that in your controllers, you do that in your model and you also have to do that in your database. It isn't any magic part. > So - if you don't _have_ to do it, don't do triggers. And if you have the > chance, design your application with a proper business logic tier, if that is > what you need - exposed via an RPC method for example. As I said, I'm from an opposite point of view... > YMMV of course... As do your requirements and discipline... -- Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
