powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / CHECK мы Справочник
11 сообщений из 11, страница 1 из 1
CHECK мы Справочник
    #37703472
PM2010
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день!

Пусть у нас на момент создания БД заказчик выделял 3 возможных значения для поля "социальный статус": школьник, рабочий, пенсионер. Разработчик сделал
Код: plsql
1.
CHECK sstatus IN ('школьник', 'рабочий', 'пенсионер').


Соответственно, в клиентском ПО "забили" 3 социальных статуса.
Прошло N-е количество времени, и заказчик вдруг захотел добавить еще социальный статус "студент". Разработчику изменить CHECK легко, да вот установить новую версию ПО, которая учитывает этот CHECK, на сотнях компьютеров заказчика по всей стране весьма затруднительно. Этого можно было бы избежать, сделав таблицу-справочник, из которой клиентское ПО бы динамически подгружало все социальные статусы. Но дополнительная таблица - это дополнительные расходы ресурсов системы.

Мне бы хотелось узнать ваши мнения по поводу того, когда же все-таки лучше использовать CHECK, а когда - справочник.
Сам я склоняюсь к тому, что CHECK следует использовать в тех случаях, когда изменение проверяемых данным CHECK'ом данных происходит настолько редко, что это реально экстраординарный случай. Например, изменение формата номера паспорта в масштабах страны, появление "третьего" пола у людей и т.п. В остальных же случаях нужно использовать справочники, дабы минимизировать необходимость внесения изменений в клиентское ПО. Верны ли мои рассуждения?

Спасибо!
...
Рейтинг: 0 / 0
CHECK мы Справочник
    #37703524
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PM2010Этого можно было бы избежать, сделав таблицу-справочник, из которой клиентское ПО бы
динамически подгружало все социальные статусы. Но дополнительная таблица - это
дополнительные расходы ресурсов системы.

Если эта таблица не связана с другими по FK, то расходы на неё без микроскопа не разглядеть.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
CHECK мы Справочник
    #37703739
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovPM2010Этого можно было бы избежать, сделав таблицу-справочник, из которой клиентское ПО бы
динамически подгружало все социальные статусы. Но дополнительная таблица - это
дополнительные расходы ресурсов системы.

Если эта таблица не связана с другими по FK, то расходы на неё без микроскопа не разглядеть.

А если связана, то в большинстве задач с микроскопом только и разглядишь.

А про редкость появления третьего пола - это Вы, PM2010, зря - даже на скульру на эту тему копья ломались :)...

И ресурсы системы на сегодня обычно полная фигня по сравнению с требованиями а-ля:
"возможность настраивать такие-то возможности без переустановки клиентского/серверного ПО".
...
Рейтинг: 0 / 0
CHECK мы Справочник
    #37703841
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> заказчик выделял 3 возможных значения для поля "социальный статус"

Dolboyobus vulgaris ваш заказчик. Просто потому, что не понимает значения определения "социальный статус".

> CHECK sstatus IN ('школьник', 'рабочий', 'пенсионер')

И ПМ с кодерами - тоже dolboyobus vulgaris. Кодеров должно было насторожить отсутствие контекста и неоднородность шкалы, менеджера - отсутствие внешних связей и фрагментарность определений.

> когда же все-таки лучше использовать CHECK, а когда - справочник

В этом примере нет справочников. Есть таблица (на самом деле набор таблиц, но для ответа на поставленный вопрос это не играет роли) с неким набором признаков.

Check в описанном вами контексте использовать не следует никогда.
...
Рейтинг: 0 / 0
CHECK мы Справочник
    #37704119
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
PM2010
Всегда справочник:
код шифр текст
1 01 школьник
2 02 рабочий
3 03 пенсионер
и всегда с изменяемым шифром и неизменяемым внутренним кодом
...
Рейтинг: 0 / 0
CHECK мы Справочник
    #37704144
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
согласен, что фиксированный справочник (enums), но проблема глубже
часто фиксированный набор делается там, где от выбора значения зависит логика, то есть вполне может быть в ХП и триггерах такой код
Код: sql
1.
if value=student then ...

и тут все будет сложнее
...
Рейтинг: 0 / 0
CHECK мы Справочник
    #37704868
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Несомненно, справочник, и несомненно, быть готовым к его расширению.
Со временем заказчик прозреет, что существуют учащиеся техникумов, военнослужащие,
священники, и другие социальные категории, к которым он притянет за уши свою бизнес-логику.

И чтобы на каждый чих не переписывать все фрагменты...

Naf
Код: sql
1.
if value=student then ...



...в справочнике можно завести поля-флаги, регулирующие бизнес-логику в отношении данной социальной категории.
Например:

КатегорияID КатегорияNAME ЛьготныйПроезд ЛьготныйПереходНаКрасныйСвет ЛьготаСтоятьПодСтрелой1Школьник1002Студент1103Пенсионер111

И тогда в коде будет:

Код: sql
1.
if ЛьготныйПроезд=1 then ...



и добавляй категорий сколько хочешь, только правильно флаги расставляй, а код будет неизменным.

PS. Поля-флаги льгот приведены здесь только для наглядности. На практике регулирование подобной бизнес-логики может потребовать целого дерева дополнительных справочников, и таблиц-связок много-ко-многим...
...
Рейтинг: 0 / 0
CHECK мы Справочник
    #37704902
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Naf
Код: sql
1.
if value=student then ...


Код: sql
1.
if value=1 then ...


где 1 - код для student
или
Код: sql
1.
if value=шифр2код('01') then ...


где 01 - шифр для student
...
Рейтинг: 0 / 0
CHECK мы Справочник
    #37705221
PM2010
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
На самом деле я пример дал надуманный. :) Просто хочется узнать критерий использования CECK'ов и справочников.
...
Рейтинг: 0 / 0
CHECK мы Справочник
    #37705232
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
PM2010На самом деле я пример дал надуманный. :)
нормальный пример. таких справочников в любой ситсеме - многие десятки
...
Рейтинг: 0 / 0
CHECK мы Справочник
    #37705246
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PM2010,

Вывод очевиден: CHECK'и не следует применять там, где нужен справочник. И вообще странная мысль - противопоставлять эти вещи.

По этой же логике, CHECK логичен там, где справочник не используется, а диапазон значений поля все же следует ограничить.

Например, если некая арифметическая процедура, согласно спецификации, была спроектирована и тестирована для работы с исходными данными от 0 до 500,000 попугаев, то и на поле "Количество попугаев" логично установить CHECK, хотя бы чтобы отсечь ошибочный ввод.
...
Рейтинг: 0 / 0
11 сообщений из 11, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / CHECK мы Справочник
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]