ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / какие ключи выбрать для данной ситуации? не могу сделать выбор.
16 сообщений из 16, страница 1 из 1
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34033601
проектант - бедолага
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
проектант - бедолага
Гость
Поискал и почитал сдешние посты по проектированию, но своей проблемой не разобрался.
Прошу совета у опытных.

Есть производство приборов.
Прибор четко характеризуется 2 параметрами - серийником и типом прибора.
Пока есть 2 варианта для ключей
1. device( serial , device_typeid , ...) - составной
2. device( deviceid , serial, device_typeid, ...) - один суррогатный

Выбор между ними сделать не могу.

Недостатки первого:.
1. серийник текстовый и длинный - тормоза с запросами - в некоторых случаях раза в 3-4 медленнее, чем при числовом поле.
2. некоторые проблемы при реализации клиентской части - при добавлении в базу уже существующего прибора пользователи хотят в разном порядке забивать параметры прибора (а за прибор отвечает несколько таблиц - эксклюзивные подкатегории или как там их)

Недостатки второго:
1. Нарушение 4-ой нормальной формы - не получается в отношениях многие-ко-многим обеспечивать уникальность комбинаций силами MS SQL (через ограничения внешнего ключа) - нужно все проверять триггерами - а таких ситуаций и очень много и ощущение кривизны от такого подхода сильное.
пример нарушение 4-ой нф

че делать?
...
Рейтинг: 0 / 0
05.10.2006, 10:08
| Ответить | Цитировать | Написать  
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34033738
Станислав С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Станислав С
Гость
проектант - бедолагаче делать?
Прежде всего, долго думать...
А нужно ли Вам в данном конкретном случае соблюдать 4НФ. Может быть все-таки хватит 3НФ?

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

Есть производство приборов.
Прибор четко характеризуется 2 параметрами - серийником и типом прибора.
Пока есть 2 варианта для ключей
1. device( serial , device_typeid , ...) - составной
2. device( deviceid , serial, device_typeid, ...) - один суррогатный

Выбор между ними сделать не могу.

Недостатки первого:.
1. серийник текстовый и длинный - тормоза с запросами - в некоторых случаях раза в 3-4 медленнее, чем при числовом поле.
2. некоторые проблемы при реализации клиентской части - при добавлении в базу уже существующего прибора пользователи хотят в разном порядке забивать параметры прибора (а за прибор отвечает несколько таблиц - эксклюзивные подкатегории или как там их)

Недостатки второго:
1. Нарушение 4-ой нормальной формы - не получается в отношениях многие-ко-многим обеспечивать уникальность комбинаций силами MS SQL (через ограничения внешнего ключа) - нужно все проверять триггерами - а таких ситуаций и очень много и ощущение кривизны от такого подхода сильное.
пример нарушение 4-ой нф

ИМХО, сама-по-себе проблема не понятна. Надо бы все рассмотреть в комплексе.

Если данные из таблицы Device попадают, например, в счет клиенту, или в накладную, или Вы печатаете гарантийный талон, или..., то я бы предпочел бы иметь один уникальный deviceid .
Если просто нужны для архива и поиска данных, то, ИМХО, без разницы...
Кроме того вопрос: а Вы что же, данные сразу кидаете в таблицу? Не ожидаете конца ввода пользователем данных? Что-то я проблему 2 первого варианта не до конца понял...
...
Рейтинг: 0 / 0
05.10.2006, 10:46
| Ответить | Цитировать | Написать  
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34033813
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Хм. Скажем так, лично я естественные ключи не люблю куда больше, нежели другие описанные Вами недостатки. Другие недостатки можно исправлять/компенсировать/обходить, а вот проблема "полгода назад мы опечатались, когда вводили серийник" никогда и никуда не уйдет, даже со сканнерами штрихкодов и прочей автоматизацией.

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

Альтернативный вариант, который можно рассмотреть - вынести серийники в отдельную таблицу, а ключ делать по (serial_id, type_id). Это позволит довольно дешево делать нужный Вам контроль целостности на уровне FK. Но несмотря на своеобразную красоту таких вот разделяемых полей FK, этот подход склонен.. накапливать неудобства, что ли, поэтому я использую его только тогда, когда знаю, что мне таким образом надо спроектировать немногочисленную группу таблиц, и эта группа не начнет стремительно разрастаться при последующих доработках.
...
Рейтинг: 0 / 0
05.10.2006, 11:00
| Ответить | Цитировать | Написать  
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34033832
проектант - бедолага
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
проектант - бедолага
Гость
2 Станислав С

в данном случае, составной ключ очень "в кассу".

слишком много случаев отношений многие-ко-многим (производственные операции, диагностика, ремонты), которые зависят от типа прибора и если использовать один суррогатный ключ, то можно навводить в базу массу нелогичных комбинаций - все это придется контролировать триггерами.

по поводу проблемы 2 второго варианта - клиент к базе пишется на Access - там есть некоторые свои особенности, которые во многих случаях упрощают жизнь, а в некоторых - наоборот. кроме того, ситуация в действительности чуть сложнее - к приборам есть комплектующие, используются эксклюзивные подкатегории и т.п.
...
Рейтинг: 0 / 0
05.10.2006, 11:04
| Ответить | Цитировать | Написать  
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34033893
проектант - бедолага
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
проектант - бедолага
Гость
softwarerХм. Скажем так, лично я естественные ключи не люблю куда больше, нежели другие описанные Вами недостатки. Другие недостатки можно исправлять/компенсировать/обходить, а вот проблема "полгода назад мы опечатались, когда вводили серийник" никогда и никуда не уйдет, даже со сканнерами штрихкодов и прочей автоматизацией.
согласен, что естественные ключи - не очень здорово и применять их стоит только в очень редких случаях. но, скажем, в MS SQL при установке связей можно указать опцию "Cascade Update Related Fields" - и проблема "полгода назад мы опечатались, когда вводили серийник" решается дешево силами сервера бд.

softwarerАльтернативный вариант, который можно рассмотреть - вынести серийники в отдельную таблицу, а ключ делать по (serial_id, type_id). Это позволит довольно дешево делать нужный Вам контроль целостности на уровне FK. Но несмотря на своеобразную красоту таких вот разделяемых полей FK, этот подход склонен.. накапливать неудобства, что ли, поэтому я использую его только тогда, когда знаю, что мне таким образом надо спроектировать немногочисленную группу таблиц, и эта группа не начнет стремительно разрастаться при последующих доработках.
тоже задумался над этим и тоже есть свои недостатки - не сходятся ежики :(

спасибо, буду думать дальше.
...
Рейтинг: 0 / 0
05.10.2006, 11:20
| Ответить | Цитировать | Написать  
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34033940
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
проектант - бедолагаи проблема "полгода назад мы опечатались, когда вводили серийник" решается дешево силами сервера бд.
Это если каскадный апдейт сумеет выполниться. С накоплением информации может нарасти такое дерево, что для изменения придется либо ждать ночи, либо выгонять пользователей.

проектант - бедолагатоже задумался над этим и тоже есть свои недостатки - не сходятся ежики :(
Не понимаю, как они могут не сойтись, если сходятся в оригинальной постановке. Пожалуй даже готов математически доказать, что такого не может быть.
...
Рейтинг: 0 / 0
05.10.2006, 11:32
| Ответить | Цитировать | Написать  
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34034121
проектант - бедолага
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
проектант - бедолага
Гость
softwarer Это если каскадный апдейт сумеет выполниться. С накоплением информации может нарасти такое дерево, что для изменения придется либо ждать ночи, либо выгонять пользователей.
да, может быть такое.
но именно эта проблема, на мой взгляд, обходима - не смертельна.

softwarerНе понимаю, как они могут не сойтись, если сходятся в оригинальной постановке. Пожалуй даже готов математически доказать, что такого не может быть.
про ежиков имелось ввиду, что "подход склонен.. накапливать неудобства" :)

но этот, альтернативный вариант, по-моему, наименее затратный.

плюс сделать один триггер на добавление/обновление записей в device_serial, что-бы исключить ситуацию, когда для одного типа прибора есть 2 одинаковых серийника.

контроль целостности хочется обеспечить за счет бд не только из-за того, что нужно будет делать меньше работы, но и сделать приложении наиболее надежным - если делать еще массу триггеров или хранимок - больше вероятность появления сделанной и пропущенной при тестах ошибки.
...
Рейтинг: 0 / 0
05.10.2006, 12:14
| Ответить | Цитировать | Написать  
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34036005
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
БОльшую часть ограничений целостности все равно декларативно задать не удастся. Тот же ФК - лишь частный случай ограничения "Быть подмножеством", каковых в реальности нужно котролировать гораздо больше чем умеют СУБД. Печально, но факт.

Кстати, а контролировать уникальность (serial, device_typeid) все равно ведь надо, даже при суррогатном ПК? Так что можно воспользоваться этим уникальным ключом и кое где навесить ФК на него, а не на ПК.
...
Рейтинг: 0 / 0
05.10.2006, 20:17
| Ответить | Цитировать | Написать  
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34036024
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
З.Ы.
В том примере про 4НФ нет нарушений. НФ проверяются только унутри отношений. Набор отношений должен проверяться на ограничения уровня БД в целом типа
IDXS(#IDX_NAME, TAB_NAME)
KEYS(#IDX_NAME, #COL_NAME)

( IDXS join KEYS ) [TAB_NAME,COL_NAME] is subset of COLS

Что СУБД должно было быть бы ФК для вьюшки. доживем наверно.
...
Рейтинг: 0 / 0
05.10.2006, 20:30
| Ответить | Цитировать | Написать  
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34036184
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Есть производство приборов.
> Прибор четко характеризуется 2 параметрами - серийником и типом прибора.

Видимо, следует читать так: _изготовленный_ прибор... далее по тексту? Серийный номер - некая уникальная последовательность? Или имеет какие-то функциональные зависимости? К чему вопросы: Ваша постановка задачи недостаточна для выбора структуры данных.
...
Рейтинг: 0 / 0
05.10.2006, 22:55
| Ответить | Цитировать | Написать  
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34036697
мпроектант - бедолага
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мпроектант - бедолага
Гость
> Видимо, следует читать так: _изготовленный_ прибор... далее по тексту?

да.
но при добавлении прибора в производство серийник присваивается базой автоматом.

> Серийный номер - некая уникальная последовательность? Или имеет какие-то функциональные зависимости?

в общем случае для каждого типа прибора - нумерация от 1 и дальше, плюс буквы.
у приборов разных типов может быть одинаковый серийник.
...
Рейтинг: 0 / 0
06.10.2006, 10:12
| Ответить | Цитировать | Написать  
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34036937
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> но при добавлении прибора в производство серийник присваивается базой
> автоматом.

Понятно.

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

Т. е. Вы посчитали достаточной уникальность (serial, device_typeid). Imho абсолютно напрасно, поскольку с уникальным серийным номером схема была бы гораздо проще и правильнее.

Ответ на Ваш вопрос: если делать "в лоб", то суррогатный ключ, отмеченный как вариант 2. Но на Вашем месте я бы переделал структуру данных.
...
Рейтинг: 0 / 0
06.10.2006, 11:18
| Ответить | Цитировать | Написать  
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34037049
проектант - бедолага
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
проектант - бедолага
Гость
guest_20040621Т. е. Вы посчитали достаточной уникальность (serial, device_typeid). Imho абсолютно напрасно, поскольку с уникальным серийным номером схема была бы гораздо проще и правильнее.
это не я посчитал.
так обстояли и обстоят дела на производстве - прибор однозначно характеризуется только связкой серийник + тип прибора.

guest_20040621Но на Вашем месте я бы переделал структуру данных.
было-бы интересно узнать, как именно
...
Рейтинг: 0 / 0
06.10.2006, 11:44
| Ответить | Цитировать | Написать  
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34037138
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> так обстояли и обстоят дела на производстве - прибор однозначно
> характеризуется только связкой серийник + тип прибора.

Хм... какая-то религия мешает серийному номеру быть уникальным? Я не вижу ни одного разумного объяснения.

> было-бы интересно узнать, как именно

Уникальные серийные номера и независимые идентификаторы.
...
Рейтинг: 0 / 0
06.10.2006, 12:05
| Ответить | Цитировать | Написать  
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34037198
проектант - бедолага
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
проектант - бедолага
Гость
> Хм... какая-то религия мешает серийному номеру быть уникальным? Я не вижу ни одного разумного объяснения.

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

> Уникальные серийные номера и независимые идентификаторы.

чем это по сути отличается от варианта 2?
deviceid - можно считать еще и уникальным серийным номером.
...
Рейтинг: 0 / 0
06.10.2006, 12:20
| Ответить | Цитировать | Написать  
какие ключи выбрать для данной ситуации? не могу сделать выбор.
    #34066624
Вопрос!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вопрос!
Гость
проектант - бедолага> Хм... какая-то религия мешает серийному номеру быть уникальным? Я не вижу ни одного разумного объяснения.

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

> Уникальные серийные номера и независимые идентификаторы.

чем это по сути отличается от варианта 2?
deviceid - можно считать еще и уникальным серийным номером.
используйте вариант 2 + констрейнт на уникальность пары serial, device_typeid
...
Рейтинг: 0 / 0
19.10.2006, 13:59
| Ответить | Цитировать | Написать  
16 сообщений из 16, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / какие ключи выбрать для данной ситуации? не могу сделать выбор.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&fpage=131&tid=1544973]:
 0ms
get settings:
 8ms
get forum list:
 18ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 59ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 61ms
get tp. blocked users:
 1ms
others: 238ms
total:  405ms
созд. / загр.: 405ms
x
x
Закрыть


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