I second your words. Using compound keys allows for much better design on several use cases where using autoincrement keys would require extra tables or extra joins (or some database denormalization to couple with the limitation of having autoincrement keys only).
Also, CRUD is important, but it is not all that hard to implement your own structure and code to be able to optimize the database. If you're dealing with massive amount of data, then database optimization is a concern. For toy projects it doesn't matter as a badly written database will probably be faster than network latency anyway... I design my database to couple with web and GUI tools. SQL Alchemy can be used independent of the interface, so it doesn't restrict me to design my application as targeting some specific environment. I also like to use all what my database offers: triggers, stored procedures / function, namespaces, views, transactions, etc. As my database is a database -- and not used only for data storage --, I have application logic in there to guarantee the consistency of the information, no matter if it is accessed from a GUI application written in Java, C, C++, Python or a web application written in any language (or even PHP ;-)). I can also use the database CLI to manipulate data and since there's code in there to prevent things from going wrong, it is safe to do maintenance through the CLI as well as take some reports or do some kinds of changes and I'm sure that data integrity is OK. What SQL Alchemy offers, then, is freedom to design and optimize the database in a way that the developer things is correct, not the way SQL Alchemy think it is or the way TG / Pylons / whatever think it is. Empowering the developer is a good thing. >From TG 0.x, we've learned a lot of things that should have been changed with regards to components. The end result from those changes gave the developer more freedom (APIs allowed for different template engines, different ORMs, use of decorators, etc.). >From TG 1.x, we've learned that freedom is good and then there's the move to TG2, where this freedom is increased through the usage of WSGI, the decoupling of several parts of TG from its core and all that leading to grant the developer a better way to design HIS / HER application. We're removing limitations and providing a clear API and tool stack to allow the developer do what HE / SHE wants. I value TG for the freedom I have. Should it be easier if we had less choices? Indeed, but then, would we be able to think better apps? Or would we be forced to write code "TG-way"? When the only tool you have is a hammer, all your problems start looking like nails. -- Jorge Godoy <[email protected]> On Sat, Apr 25, 2009 at 12:48 PM, Dan F <[email protected]> wrote: > > mdipierro wrote: > > This brings up a question I have and I have not had a decent answer > > to. Other than for accessing legacy databases why would one need > > SQLAlchemy over the web2py DAL? What functionality is missing in th > > web2py DAL that is in SQLAlchemy? Please understand I am not trying to > > be polemic, far from it, I am trying to learn from you so that we can > > improve. > > > > It's not just "legacy" databases. Calling them legacy makes it sound > like only old databases are designed against the wishes of ORMs like > web2py. I know quite a few developers who simply won't tolerate poor > table structure, and too often these ORM's dictate a pattern that is > less than ideal (as I have defined it ;-) ). Disallowing/discouraging > compound primary keys, for example, sacrifices traditional design to > make it easier on ORM developers, or in the case of web2py, to allow it > to be abstracted to even allow non-relational databases. > > Anyway, I consider traditional design to be important. I prefer my > model to be proscriptive as well as descriptive. The more I can get my > data model working to define structure, the less pain later. There's a > large class of developers who don't really care. That's fine, and maybe > they won't ever need to use a fuller extent of the database's power > anyway, but I have yet to see this as the "future" of web apps that > throws most databases I've seen into the "legacy" category. Plus it > assumes that I have full control over the database, and that the > database is used for no other purpose or at least mainly used by that DAL. > > Does the web2py DAL allow batch updates etc. to occur without recourse > to actual SQL statements? i.e., updating all columns in the database > without making a call per record? If not, functionality like this gives > SQLAlchemy perhaps another benefit. > > I'm interested to hear what others think of this. Is the database > structure less important than I'm making it out to be? > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
