|
|
|
CHECK мы Справочник
|
|||
|---|---|---|---|
|
#18+
Добрый день! Пусть у нас на момент создания БД заказчик выделял 3 возможных значения для поля "социальный статус": школьник, рабочий, пенсионер. Разработчик сделал Код: plsql 1. Соответственно, в клиентском ПО "забили" 3 социальных статуса. Прошло N-е количество времени, и заказчик вдруг захотел добавить еще социальный статус "студент". Разработчику изменить CHECK легко, да вот установить новую версию ПО, которая учитывает этот CHECK, на сотнях компьютеров заказчика по всей стране весьма затруднительно. Этого можно было бы избежать, сделав таблицу-справочник, из которой клиентское ПО бы динамически подгружало все социальные статусы. Но дополнительная таблица - это дополнительные расходы ресурсов системы. Мне бы хотелось узнать ваши мнения по поводу того, когда же все-таки лучше использовать CHECK, а когда - справочник. Сам я склоняюсь к тому, что CHECK следует использовать в тех случаях, когда изменение проверяемых данным CHECK'ом данных происходит настолько редко, что это реально экстраординарный случай. Например, изменение формата номера паспорта в масштабах страны, появление "третьего" пола у людей и т.п. В остальных же случаях нужно использовать справочники, дабы минимизировать необходимость внесения изменений в клиентское ПО. Верны ли мои рассуждения? Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2012, 18:39 |
|
||
|
CHECK мы Справочник
|
|||
|---|---|---|---|
|
#18+
PM2010Этого можно было бы избежать, сделав таблицу-справочник, из которой клиентское ПО бы динамически подгружало все социальные статусы. Но дополнительная таблица - это дополнительные расходы ресурсов системы. Если эта таблица не связана с другими по FK, то расходы на неё без микроскопа не разглядеть. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2012, 19:10 |
|
||
|
CHECK мы Справочник
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovPM2010Этого можно было бы избежать, сделав таблицу-справочник, из которой клиентское ПО бы динамически подгружало все социальные статусы. Но дополнительная таблица - это дополнительные расходы ресурсов системы. Если эта таблица не связана с другими по FK, то расходы на неё без микроскопа не разглядеть. А если связана, то в большинстве задач с микроскопом только и разглядишь. А про редкость появления третьего пола - это Вы, PM2010, зря - даже на скульру на эту тему копья ломались :)... И ресурсы системы на сегодня обычно полная фигня по сравнению с требованиями а-ля: "возможность настраивать такие-то возможности без переустановки клиентского/серверного ПО". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2012, 21:57 |
|
||
|
CHECK мы Справочник
|
|||
|---|---|---|---|
|
#18+
> заказчик выделял 3 возможных значения для поля "социальный статус" Dolboyobus vulgaris ваш заказчик. Просто потому, что не понимает значения определения "социальный статус". > CHECK sstatus IN ('школьник', 'рабочий', 'пенсионер') И ПМ с кодерами - тоже dolboyobus vulgaris. Кодеров должно было насторожить отсутствие контекста и неоднородность шкалы, менеджера - отсутствие внешних связей и фрагментарность определений. > когда же все-таки лучше использовать CHECK, а когда - справочник В этом примере нет справочников. Есть таблица (на самом деле набор таблиц, но для ответа на поставленный вопрос это не играет роли) с неким набором признаков. Check в описанном вами контексте использовать не следует никогда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2012, 22:51 |
|
||
|
CHECK мы Справочник
|
|||
|---|---|---|---|
|
#18+
PM2010 Всегда справочник: код шифр текст 1 01 школьник 2 02 рабочий 3 03 пенсионер и всегда с изменяемым шифром и неизменяемым внутренним кодом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2012, 09:23 |
|
||
|
CHECK мы Справочник
|
|||
|---|---|---|---|
|
#18+
согласен, что фиксированный справочник (enums), но проблема глубже часто фиксированный набор делается там, где от выбора значения зависит логика, то есть вполне может быть в ХП и триггерах такой код Код: sql 1. и тут все будет сложнее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2012, 09:35 |
|
||
|
CHECK мы Справочник
|
|||
|---|---|---|---|
|
#18+
Несомненно, справочник, и несомненно, быть готовым к его расширению. Со временем заказчик прозреет, что существуют учащиеся техникумов, военнослужащие, священники, и другие социальные категории, к которым он притянет за уши свою бизнес-логику. И чтобы на каждый чих не переписывать все фрагменты... Naf Код: sql 1. ...в справочнике можно завести поля-флаги, регулирующие бизнес-логику в отношении данной социальной категории. Например: КатегорияID КатегорияNAME ЛьготныйПроезд ЛьготныйПереходНаКрасныйСвет ЛьготаСтоятьПодСтрелой1Школьник1002Студент1103Пенсионер111 И тогда в коде будет: Код: sql 1. и добавляй категорий сколько хочешь, только правильно флаги расставляй, а код будет неизменным. PS. Поля-флаги льгот приведены здесь только для наглядности. На практике регулирование подобной бизнес-логики может потребовать целого дерева дополнительных справочников, и таблиц-связок много-ко-многим... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2012, 14:43 |
|
||
|
CHECK мы Справочник
|
|||
|---|---|---|---|
|
#18+
Naf Код: sql 1. Код: sql 1. где 1 - код для student или Код: sql 1. где 01 - шифр для student ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2012, 15:03 |
|
||
|
CHECK мы Справочник
|
|||
|---|---|---|---|
|
#18+
На самом деле я пример дал надуманный. :) Просто хочется узнать критерий использования CECK'ов и справочников. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2012, 17:25 |
|
||
|
CHECK мы Справочник
|
|||
|---|---|---|---|
|
#18+
PM2010На самом деле я пример дал надуманный. :) нормальный пример. таких справочников в любой ситсеме - многие десятки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2012, 17:31 |
|
||
|
CHECK мы Справочник
|
|||
|---|---|---|---|
|
#18+
PM2010, Вывод очевиден: CHECK'и не следует применять там, где нужен справочник. И вообще странная мысль - противопоставлять эти вещи. По этой же логике, CHECK логичен там, где справочник не используется, а диапазон значений поля все же следует ограничить. Например, если некая арифметическая процедура, согласно спецификации, была спроектирована и тестирована для работы с исходными данными от 0 до 500,000 попугаев, то и на поле "Количество попугаев" логично установить CHECK, хотя бы чтобы отсечь ошибочный ввод. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2012, 17:38 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=37704902&tid=1541800]: |
0ms |
get settings: |
7ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
195ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 212ms |
| total: | 497ms |

| 0 / 0 |
