Databases and PythonΒΆ

Schemas change; we add columns and tables, we change views.  Additionally, we make performance tweaks like modifying indexes or table locations.

However, a schema – the tables, columns, indexes and what-not – must have a tidy, easy-to-use version number.  A piece of software should depend on schema version 2.x; when the schema changes from 2.3 to 2.4, we expect software to work; when we change to version 3.1, we expect software to break.

Here are some ways to handle this.

Stored Procedures are notoriously hard to manage.  In order to support production, training, development and various levels of testing, you wind up with several databases each of which has slightly different versions of the stored procedures.  And there’s no easy comparison between them.  You can avoid this nightmare through some simple technical choices.
Denormalization – like Normalization – is a buzzword that can be interpreted several ways.  It can mean “duplicated data”, or it can mean “alternate forms of normalization.”  It’s a loaded word, and it leads directly to at least five different kinds of objections.
The name is obscure, the math isn’t obvious,  but this is a genius play for data analysis applications.  Thanks!
When in doubt, step away from the IDE – stop typing – start thinking.  Here are some epic non-solutions to a standard, well-understood problem.
I saw a great opinion piece on “simplification” – one that lands squarely on the Django sweet-spot of “model + admin first, reporting second”. It makes perfect Agile sense, and it really does simplify things.

See Cubulus and Alexandru Toth ‘s page.  This is very nice to see advanced work done on the dimensional model.

This is interesting because it eschews traditional star-schema SQL for a technique apparently called “Multidimensional Hierarchical Clustering”.

Before I could finishing thinking about the problem, it was already fixed!  After looking around at ORM tools (in “Python Object-Relational Mapping (Revised) ”), and attending PyCon 2007, I began to like the look of SQLAlchemy .  I was happy until I uncovered something (“SELECT with group by UNION select drops the group by clause ”) that was pretty obscure, and didn’t work perfectly.  And the bug fix flew by so quickly, I was amazed.
Just got a note on new developments at projects.amor.org . Specifically, Dejavu ‘s analysis module has a crosstab function that looks vaguely familiar to me.
This one is called “ActiveWarehouse ” and is a Ruby/Rails project. However, the ActiveWarehouse Example , which shows an implementation which parallels my Python implementation nicely.
I’ve had this conversation in several different forms. It’s a subtle, gray-area question about data warehousing. I think there’s a right answer, but getting others to see that answer is challenging.
This is a tougher list to create, where is the line between object persistence and OODB? And where does ORM fit?
Time to collect a number of Object-Relational mapping and Database driver links in one place. Specifically, some Oracle-related questions have lifted a need to get cx_Oracle installed and running and quit messing around with mx.ODBC. I don’t need the perfect portability of ODBC. I need access to Oracle features.
Building Skills Content Management Culture of Complexity Data Structures and Algorithms Databases and Python DocBook Economics of Software Macintosh Methodology for Non-Programmers Open Source Projects Personal Web Toys Technology News Test Driven Reverse Engineering The Lure of XML Unit Testing in Python User Interface War Stories and Advice

Previous topic

Why Are Things So Complicated? - 7 Deadly Reasons?

Next topic

The Schema Evolution Problem

This Page