Re: We aren't a relational database ... ?
От | Jeff Davis |
---|---|
Тема | Re: We aren't a relational database ... ? |
Дата | |
Msg-id | 1191811994.26301.43.camel@jdavis обсуждение исходный текст |
Ответ на | We aren't a relational database ... ? ("Marc G. Fournier" <scrappy@postgresql.org>) |
Ответы |
Re: We aren't a relational database ... ?
|
Список | pgsql-advocacy |
On Sun, 2007-10-07 at 22:58 -0300, Marc G. Fournier wrote: > "How many open source relational databases can you name? My friend Gabrielle > recently sent me the links to two of them. However, if you?re like most > technical people, you probably don?t know any ? just as I didn?t until > recently. I can already imagine many of you saying ?bulls**t?, what about MySQL > and PostgreSQL?? (to name just two), but those are just databases, not > relational databases." SQL does have some glaring violations of the relational model, the duplicate rows are just one example. You can't even compare two relation values in SQL; I'm not sure whether that's required by the relational model or not, but it certainly seems to show that relations were not the real design focus of the language. I think PostgreSQL is a good representative of the spirit of the relational model in other ways though. It's easy to define your own types that are every bit as powerful as built-in types. And the rule system is specifically designed to help separate the logical design from the physical storage (although the rule system could probably be better at this), which is an important benefit of relational theory. And we shouldn't forget that SQL is a lot closer to a relational language than any other practical alternative, which may be why it's so successful. That being said, I'd like to see some group really make an effort to build a truly relational database. If they are able to achieve the theoretical benefits of the relational model, that would be very worthwhile. And the benefits aren't too far-fetched. It's much easier for the optimizer to transform relational expressions than SQL expressions. And if you write declarative constraints as relational expressions (rather than triggers), the optimizer is able to use those constraints as part of the optimization process. PostgreSQL is able to do that for simple things like unique attributes or constraint exclusion, but for more complex constraints you need to use triggers, which the optimizer can't see. Regards, Jeff Davis
В списке pgsql-advocacy по дате отправления: