Re: Database design: Storing app defaults
От | Jonathan Bond-Caron |
---|---|
Тема | Re: Database design: Storing app defaults |
Дата | |
Msg-id | 003601c8d146$b4f462d0$1edd2870$@com обсуждение исходный текст |
Ответ на | Database design: Storing app defaults (David <wizzardx@gmail.com>) |
Ответы |
Re: Database design: Storing app defaults
|
Список | pgsql-general |
Application defaults go in the application code not in the database (my opinion). If you wants user, group, whatever customizable defaults, they belong in the database schema i.e. table user_prefs or role_prefs For your question about "backwards compatible database", in most cases apps and databases schemas are upgraded at the same time. If you have a requirement that old & new apps have to work on the same database schema then don't make database schemas changes that will not be backwards compatible / break older apps. Put those changes on hold until both apps & databases can be upgraded. Some solutions which may help you java (hibernate) adds a version column to each table, rails adds a schema_info table with database version. The are many ways of managing applications upgrades, it's an mainly an application challenge not a database design issue. -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of David Sent: June 18, 2008 8:03 AM To: pgsql-general@postgresql.org Subject: [GENERAL] Database design: Storing app defaults Hi list. If you have a table like this: table1 - id - field1 - field2 - field3 table2 - id - table1_id - field1 - field2 - field3 table1 & table2 are setup as 1-to-many. If I want to start providing user-customizable defaults to the database (ie, we don't want apps to update database schema), is it ok database design to add a table2 record, with a NULL table1_id field? In other words, if table1 has no matching table2 record, then the app will use the table2 record with a NULL table1_id field to get defaults. This looks messy however. Is there a better way to do it? A few other ways I can think of: 1) Have an extra table1 record (with string fields containing 'DEFAULT'), against which the extra table2 record is linked. 2) Have a new table, just for defaults, like this: table2_defaults - field1 - field2 - field3 Which is the cleanest way? Is there another method I should use instead? David. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
В списке pgsql-general по дате отправления: