On Tue, Nov 25, 2014 at 4:31 PM, Frank Millman <fr...@chagford.com> wrote: > > "Dennis Lee Bieber" <wlfr...@ix.netcom.com> wrote in message > news:lrr67al6ppa852agu9rq2dstqtue17i...@4ax.com... >> We must have a different impression of what a "schema" consists of. As >> I learned it, the "schema" basically came down to the statements defining >> the form of the data, the rules (triggers) on it, and the relationships >> between data items. http://en.wikipedia.org/wiki/Database_schema >> > > I also find it confusing. The same word is used by different RDBMS's to mean > different things.
They're not entirely different; in both cases, your database schema is, broadly speaking, the structure of your tables and the relationships between them. Consider the "schema" to be the design document that lays out your data. Then you have two derivative forms of it: one is what's usually called DDL, and is executable statements; the other derives from the concept that one schema represents one logical dataset, so another schema would represent a different logical dataset, so you have named schemas. Since SQLite3 doesn't have the concept of named schemas, it uses "schema" solely in the sense of DDL. The SQL spec (and therefore PostgreSQL) uses it in both senses. > I find that schemas gives me the advantages of both without the > disadvantages. Yep. So, use a real database, with better compliance to the spec :) What you have is similar to what I've done in a number of different database systems; schemas to separate related sets of tables into namespaces, and other schemas to store global/shared data, all inside a single database. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
