> 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.
This has nothing to do with application logic by itself. The performance issue - and I spare you the premature optimization talk - depends on the right indices created and carefully tailored queries. Nothing I'm against. But application LOGIC is code running. In triggers and/or stored procedures, and a stupid algorithm is a stupid algorithm - regardless of the language. > > - 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. I didn't talk about SQL here. But about PL/SQL, java or whatever your DB uses as language for triggers and procedures. We're talking logic here, not SQL-statements. > > - 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. I don't understand that. > > - 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. I already aknowledged that, however the amounts of discipline to muster increase - and in an imperfect world, I'd rather strive for less discipline needed. > 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. So far, I've not run into such difficulties in my current commercial TG app. And as long as I can work with ORM without the need for too complicated queries, I don't see a reason why I can't continue to work that way. Leaving stored procedures out of the game will certainly keep that state up as long as possible - maybe until I'm finished... *keeps fingers crossed* > 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. The difference is when I want to inspect the black-box. Then I need to look into the database, and especially when I use triggers, that can be tedious. Granted, metaclasses, decorators and monkey-patching can do that to my python code 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? It's not about documentation. That is a general thing of course. Its about having a bunch of python code sitting on my harddrive that I can rummage through. And if I encounter a sql-statement - especially when using SO/SA - I know exactly what happens (or at least I can presume that there is no business logic happening, but simple storage/retrieval). But when your design relies on SP/Triggers, a simple insert could cause a huge cascade of stuff happening without me realizing. As I mentioned several times: side-effects can happen everywhere. But I try to minimize them, and only bring them into play where there is a real benefit. I fail to see why some insert <whatever> should trigger a insert <something else> automagically, where I could just issue these two statements after another - in python code! The necessity to trigger things or to encapsulate comes into play when one wants the DB to be the API programmers work against. But then I'd rather offer them a OO-style python API that is much richer in expression and features, and even allows me to change things behind the curtains in a much more radical fashion. > > - 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 :-) My side is pretty clear: data in the database, logic in a logic tier. Where do you see the need for me to pick anything? > As I said, I'm from an opposite point of view... Yup :) And I don't bother much, I just wanted to state another stance as the discussion was about options one can take. No bad feelings here :) -- >> Diez B. Roggisch >> Developer T +49 (30) 443 50 99 - 27 F +49 (30) 443 50 99 - 99 M +49 (179) 11 75 303 E [EMAIL PROTECTED] >> artnology GmbH A Milastraße 4 / D-10437 Berlin T +49 (30) 443 50 99 - 0 F +49 (30) 443 50 99 - 99 E [EMAIL PROTECTED] I http://www.artnology.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
