
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
19.09.2013, 13:14
|
|||
|---|---|---|---|
|
|||
Необходимость в использовании множества справочников |
|||
|
#18+
Друзья, нужна помощь в понимании концепции. Начну сразу с примера. В какой-либо организации заводим информацию сотрудниках. Информация стандартная: ФИО, адрес, паспортные данные, образование, воинская обязанность и т.д. Некоторые из этих полей свободны для ввода значений (ФИО, адрес), другие же имеет смысл делать списком (предоставлять выбор значений). Например, образование у нас имеет фиксированные и повторяющиеся значения, воинские звания, годность - аналогично. Соответственно возникает вопрос о создании справочников, таких как: "Вид образования", "Воинское звание", "Годность к службе". В общем, вопрос состоит в том, насколько корректно использование множества справочников, структура которых примитивна: 2 поля (ID и текстовое описание)? Множество это, разумеется, может быть приличным по объему. Вше я привел лишь несколько примеров. Дело в том, что руководитель считает использование подобных справочников бессмысленно. Однако альтернатив никаких не подсказывает. Откройте секрет, пожалуйста :) Благодарю! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 13:24
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1Друзья, нужна помощь в понимании концепции. Начну сразу с примера. В какой-либо организации заводим информацию сотрудниках. Информация стандартная: ФИО, адрес, паспортные данные, образование, воинская обязанность и т.д. Некоторые из этих полей свободны для ввода значений (ФИО, адрес), другие же имеет смысл делать списком (предоставлять выбор значений). Например, образование у нас имеет фиксированные и повторяющиеся значения, воинские звания, годность - аналогично. Соответственно возникает вопрос о создании справочников, таких как: "Вид образования", "Воинское звание", "Годность к службе". В общем, вопрос состоит в том, насколько корректно использование множества справочников, структура которых примитивна: 2 поля (ID и текстовое описание)? Множество это, разумеется, может быть приличным по объему. Вше я привел лишь несколько примеров. Дело в том, что руководитель считает использование подобных справочников бессмысленно. Однако альтернатив никаких не подсказывает. Откройте секрет, пожалуйста :) Благодарю! Любое "поле" связано с понятием "классификатора". Когда Вы введете в поле "Фамилия" значение "Петров" - Вы отнесете человека к классу людей, имеющих фамилию Петров. Аналогично по любому другому полю (формально - абсолютно по любому). Ваш руководитель, концептуально, прав - раз Вы не заводите справочник по Фамилии, почему его необходимо заводить по другим полям? Аргумент - ограниченное число значений - не является убедительным. Как провести границу? Несколько более убедительным (но тоже не достаточно) является аргумент, что два атрибута: код и наименование. В СУБД для таких случаев используется специальный тип свойства. Который как раз и отличается тем, что его значение состоит из двух атрибутов. Разумеется, можно так же использовать и стандартное решение с отдельными таблицами и "ключами". Поскольку СУБД в Вашем распоряжении просто нет именно его Вам и нужно использовать)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 13:25
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1, Использование справочников всегда оправдано, когда используются связи pk-fk. Но можно немного извернуться. Создается таблица с id_справочника, id значения, значение. (т.е. одна таблица на множество справочников) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 13:26
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1, Использование справочников всегда оправдано, когда используются связи pk-fk. Но можно немного извернуться. Создается таблица с id_справочника, id значения, значение. (т.е. одна таблица на множество справочников) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 13:35
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1В общем, вопрос состоит в том, насколько корректно использование множества справочников, структура которых примитивна: 2 поля (ID и текстовое описание)? если вы точно знаете, что количество значений и сами значения не изменятся никагда , то вполне можно обойтись перечислением, например есть только два пола: "муж" и "жен", если же значения могут добавляться/изменяться в процессе работы, то Пользователи должны иметь возможность делать это сами, а не искать программиста, и образование, и воинские звания я бы вынес в справочники - они могут измениться после какого-нить чиха любимого Правительства, либо на момент сдачи проги в эксплуатацию будут заполнены не все значения, либо они будут отличаться в другой от вашей стране, в которую вы захотите свою продать ИМХО - это единственный критерий ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 13:41
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1В общем, вопрос состоит в том, насколько корректно использование множества справочников, структура которых примитивна: 2 поля (ID и текстовое описание)? если же вопрос состоит в том - сделать один справочник на всех, или по справочнику каждому... дело вкуса, мне EAV для таких задач очень не нравится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 13:46
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1Соответственно возникает вопрос о создании справочников, таких как: "Вид образования", "Воинское звание", "Годность к службе". В общем, вопрос состоит в том, насколько корректно использование множества справочников, структура которых примитивна: 2 поля (ID и текстовое описание)? Множество это, разумеется, может быть приличным по объему. Вше я привел лишь несколько примеров. Дело в том, что руководитель считает использование подобных справочников бессмысленно. Однако альтернатив никаких не подсказывает.1. Названия значений могут меняться 2. Защита от неправильного ввода (это можно проверять чек-констрейном, но не полностью - в справочниках можно выделить актуальные значения для ввода, и при этом не запрещать существование старых значений) 3. Простота сопровождения кода ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 13:47
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
lLocustВ_поисках_1, Использование справочников всегда оправдано, когда используются связи pk-fk. Но можно немного извернуться. Создается таблица с id_справочника, id значения, значение. (т.е. одна таблица на множество справочников) Изворачиваться не нужно. Так как возникнут другие проблемы (например, поддержка ОЦ), то есть, Вы будете вовлечены в цепочку изворачиваний)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 14:06
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
Бредятина, Это да, я то же не сторонник такого подхода... просто съакцентировался на авторОднако альтернатив никаких не подсказывает. Вот и предложил ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 15:14
|
|||
|---|---|---|---|
|
|||
Необходимость в использовании множества справочников |
|||
|
#18+
В общем, решил выложить текущую разработку. Если не сложно, гляньте одним глазком, пожалуйста. Просьба не пугаться - там все примитивно. Итак, в наличии аж 15 справочников: TSprOrg - список организаций (в которых ранее состоял сотрудник) TSprTown - список городов (где ранее работал сотрудник) TSprTypeOtp - виды отпуска (без сохранения, с сохр., ...) TSprStatus - виды родства (муж, жена, дочь, ...) TSprTypeDocEdc - виды документов об образовании (удостоверение, аттестат, диплом, ...) TSprProf - наименование профессий + привязка к подразделению TSprSemP - семейное положение (женат, замужем, холост, ...) TSprGr - гражданство TSprEdc - вид образования (среднее-специальное, высшее, ...) TSprServ - список подразделений TSprLang - список языков (какими владеет сотрудник) TSprLngLevel - уровень владения языком (со словарем, ...) TSprWarVz - воинское звание (рядовой, матрос, ...) TSprWarSpec - воинская специальность TSprWarGodn - категории годности к воинской службе Собственно, все справочки открыты для редактирования/добавления данных. И вот руководитель считает, что смысла в этих справочниках нет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 16:02
|
|||
|---|---|---|---|
|
|||
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1И вот руководитель считает, что смысла в этих справочниках нет... А вбивать значения он сам будет ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 16:04
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1И вот руководитель считает, что смысла в этих справочниках нет...я ничего радикально лишнего не увидел, разве что семейное положение да степень родства, их вполне можно делать перечислениями возникают вопросы из разряда " это где, зачем и кому нужны эти данные? " может и ваш руководитель именно это имеет в виду? что не нужна никому эта информация? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 16:39
|
|||
|---|---|---|---|
|
|||
Необходимость в использовании множества справочников |
|||
|
#18+
Chop, хм... А может Вы и правы - может имелась в виду необходимость в семантическом плане. Уточню, спасибо :-) Насчет перечислений - не могли бы пояснить что имеется в виду? Хранение данных не в самой БД, а где-то еще? Ни разу не сталкивался... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 16:43
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1 Вы все правильно делаете. Не хочу разводить тут теоретические измышления, просто на основании более чем 25-летнего опыта работы разработки ПО (со множеством разных СУБД), многократно убедился в том, что любые данные, которые можно представить в виде справочника, должны быть им представлены. И точка. Хотя бы потому, что все равно рано или поздно это придется сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 17:05
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1В общем, вопрос состоит в том, насколько корректно использование множества справочников, структура которых примитивна: 2 поля (ID и текстовое описание)? Абсолютно 100% корретктно. В_поисках_1Множество это, разумеется, может быть приличным по объему. Вше я привел лишь несколько примеров. Дело в том, что руководитель считает использование подобных справочников бессмысленно. Однако альтернатив никаких не подсказывает. Другое дело -- множество одинаковых справочников просто тупо долго делать. Альтернатива -- универсальные справочники (справочник, в котором в ПК хранится ещё и тип справочкика) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 17:06
|
|||
|---|---|---|---|
|
|||
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1Насчет перечислений - не могли бы пояснить что имеется в виду? Хранение данных не в самой БД, а где-то еще? Ни разу не сталкивался... В коде программы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 17:21
|
|||
|---|---|---|---|
|
|||
Необходимость в использовании множества справочников |
|||
|
#18+
_мод, понял, спасибо. MasterZiv, MasterZivДругое дело -- множество одинаковых справочников просто тупо долго делать. Альтернатива -- универсальные справочники (справочник, в котором в ПК хранится ещё и тип справочкика) Т.е положим есть множество справочников, у которых схожие поля => можно создать один справочник из этих повторяющихся полей и соединять данный универсальный справочник с другими "дочерними" справочниками, поля у которых уникальны по отношению друг к другу. Вы это имели в виду? d7i, d7iНе хочу разводить тут теоретические измышления, просто на основании более чем 25-летнего опыта работы разработки ПО (со множеством разных СУБД), многократно убедился в том, что любые данные, которые можно представить в виде справочника, должны быть им представлены. И точка. Хотя бы потому, что все равно рано или поздно это придется сделать. Я Вас понял. Просто хотелось бы выявить приемлемый аргумент (который бы устроил всяких профессоров-д.т.н.'ов), оправдывающий наличие справочников. Я вижу этот аргумент в таком виде - лень/удобство/экономия времени. Так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 17:33
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1Просто хотелось бы выявить приемлемый аргумент (который бы устроил всяких профессоров-д.т.н.'ов), оправдывающий наличие справочников. Я вижу этот аргумент в таком виде - лень/удобство/экономия времени.Написали несколько списков аргументов, они вполне подойдут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 17:59
|
|||
|---|---|---|---|
|
|||
Необходимость в использовании множества справочников |
|||
|
#18+
> в наличии аж 15 справочников Вы напрасно обозвали их справочниками. Статус официального административно-территориального деления - не то же самое, что ваши представления о языках или уровнях владения ими. > руководитель считает, что смысла в этих справочниках нет... Значит, он ничего не знает о проектировании. Так бывает, это нормально. Количество сущностей стандартных данных не должно вас смущать, на самом деле их гораздо - на порядки - больше пятнадцати. В вашей структуре не отражена контекстная зависимость. Скажем, однополые браки могут быть разрешены на части территории государства. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 18:02
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1 Справочники используются для условно-постоянных данных. Позволяют (пишу с ходу): - структуризировать данные (более понятная, четкая структура БД) - обеспечить надежную идентификацию (исключает ошибки при вводе, так как вместо ввода данных используется выбор из справочника) - упростить обслуживание (модификацию), т.е. переложить ее на пользователя. К тому же данные в справочник вводятся однократно ,что упрощает их верификацию - получить большую безопасность (проще организовать разграниченный по уровням доступ к данным) Ну и многое другое, о чем с ходу и не упомнить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 18:38
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
Идея универсального справочника (как и EAV) просто обязана придти в голову каждому начинающему проектировщику. Однако взамен сомнительного сокращения количества таблиц (кому оно мешало) получаем ослабление ссылочной целостности, лишнее связывание разнородных сущностей (а вдруг понадобится права по разному раздавать, или репликацию организовывать) и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 18:56
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1, я бы на вашем месте во всех справочниках сделал бы поля одинаково названными: ID и Name, например. Префиксы и суффиксы ничего полезного не несут, а хлопот в будущем могут доставить изрядно, начиная от написания запросов, и заканчивая разработкой универсального пользовательского интерфейса для такого рода справочников. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 19:23
|
|||
|---|---|---|---|
|
|||
Необходимость в использовании множества справочников |
|||
|
#18+
> данные в справочник вводятся однократно ,что упрощает их верификацию Административно-территориальное деление, например, по сути своей имеет темпоральный характер. Глобальный смысл выделения условно постоянных данных - разные внешние источники данных, разный жизненный цикл данных, использование разного контекста. Ну, и стандартные правила проектирования, разумеется, - как обобщенный практический критерий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 21:36
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1 MasterZiv, MasterZivДругое дело -- множество одинаковых справочников просто тупо долго делать. Альтернатива -- универсальные справочники (справочник, в котором в ПК хранится ещё и тип справочкика) Т.е положим есть множество справочников, у которых схожие поля => можно создать один справочник из этих повторяющихся полей и соединять данный универсальный справочник с другими "дочерними" справочниками, поля у которых уникальны по отношению друг к другу. Вы это имели в виду? Наверняка я имел в виду не это, поскольку из этого я нихрена не понял. Я имел в виду следующее: Допустим, имеем справочники: NAME (id -> name) SURNAME (id -> name) PATRONYMIC (id -> name) GENDER( id-> name) Мы можем все эти справочники реализовать универсальным справочником: UNIDICT (id -> dict_type{'NAME','SURNAME','PATRONYMIC','GENDER'}, name) Нотация такая: ТАБЛИЦА ( первичный ключ -> поля атрибутов ) атрибут { список возможных значений через запятую } ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2013, 22:42
|
|||
|---|---|---|---|
Необходимость в использовании множества справочников |
|||
|
#18+
В_поисках_1Насчет перечислений - не могли бы пояснить что имеется в виду? Хранение данных не в самой БД, а где-то еще? Ни разу не сталкивался...жестко заданный набор значений для поля, задается на этапе программирования системы, в 1С это отдельный тип метаданных, называется перечисление в отличие от справочника, в MySQL - тип поля SET/ENUM в других БД может еще как-то ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=32&mobile=1&tid=1541113]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
158ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 10ms |
| total: | 275ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...