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

Reply via email to