powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Ещё более нелепый вопрос для опытных профессионалов
14 сообщений из 39, страница 2 из 2
Ещё более нелепый вопрос для опытных профессионалов
    #36254139
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Microbit wrote:
Прочитал более детально.
> человека. Из этой таблицы имеется 3 ссылки по вторичным ключам на три
> отдельные таблицы, каждая из которых представляет, соответственно,
> фамилии, имена, отчества. Предметная область не предполагает
> лингвистический анализ имен и фамилий :) То есть таким образом
> описываются обычные клиенты - физические лица.

На самом деле особенно тут ничего плохого нет, за исключением
одной особенности:

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

Ну и далее надо думать, что вы чаще делаете: выборки
из fio БЕЗ полей имя, фамилию и отчество, это будет быстрее,
если этих полей нет в fio (за счёт длины записи),
или же выборки с fio, это может быть медленнее за счёт необходимости
3-х лишних JOIN-ов.

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

Вообще, это называется декомпозиция, не приводящая ни к устранению
аномалий, ни к уменьшению объёма данных. Её можно сделать, но
бесполезно, так как у новой сущности нет неключевых атрибутов,
только имя.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Ещё более нелепый вопрос для опытных профессионалов
    #36254146
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Нормальный подход - имеет право на жизнь.

Я бы расширил: использовал правила именования, сдвоенные имена, языковые эквиваленты.
...
Рейтинг: 0 / 0
Ещё более нелепый вопрос для опытных профессионалов
    #36255035
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
baracsalexeyvgА наличие сущности справочника фамилий с констрейном не запретит программе ввести неправильно фамилию в справочник и потом правильно запомнить ИД этой фамилии в поле значения фамилии в таблице.
А чтобы кто попало не правил системные справочники, существует разделение доступа пользователей к объектам БД...Так если программисты в клиентском приложении предусмотрят ввод фамилий, то они уж, наверное, дадут доступ :-)

А если вы про деление ролей в бизнес-процессе, типа:

Оператор ввода имён
Оператор ввода отчеств
Оператор ввода фамилий
Оператор ввода оперативных транзакций (он уже при обнаружении отсутствующих данных в справочниках пишет служебку для добавления первыми тремя людьми этих данных)

то думаю, это не совсем правильно :-)
...
Рейтинг: 0 / 0
Ещё более нелепый вопрос для опытных профессионалов
    #36255241
baracs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvgbaracsА чтобы кто попало не правил системные справочники, существует разделение доступа пользователей к объектам БД...Так если программисты в клиентском приложении предусмотрят ввод фамилий, то они уж, наверное, дадут доступ :-)
Доступ дают не программисты а DBA.
alexeyvgА если вы про деление ролей в бизнес-процессе
Именно!
Должен быть оператор, вбивающий информацию строго в соответствии с бизнес-правилами и использующий для этого системные справочники. Вводить отсебятину ему не позволит грамотно сделанный интерфейс.
И, скажем, администратор (начальник, хозяин) базы данных. Не путать с DBA!
Он отвечает за качество информации в БД. Не за доступ, не за настройки сервера, не за backup-ы, а именно за информационное наполнение БД. И, вот, именно он по служебкам или устным просьбам операторов - это уже другой вопрос - корректирует системные справочники.
И с разработчиками и DBA общается тоже он.

alexeyvgто думаю, это не совсем правильно :-)
Думайте что хотите
Но по-другому, БД быстро превратится в свалку трудноиспользуемой информации.
...
Рейтинг: 0 / 0
Ещё более нелепый вопрос для опытных профессионалов
    #36255933
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
baracsalexeyvgто думаю, это не совсем правильно :-)
Думайте что хотите
Но по-другому, БД быстро превратится в свалку трудноиспользуемой информации.Это просто эмоции - количественных критериев нет. Без количественных критериев любая реально используемая база - помойка (вряд ли можно найти базу без хотя-бы одной ошибки).

Вряд-ли есть хоть одна реально используемая система с упомянутой мной бизнес-лигикой ввода фио (мной - как шутки, вами - серьёзно). Конечно, если не брать специальные системы, для которых важно вести справочники ф. и. о. отдельно.
...
Рейтинг: 0 / 0
Ещё более нелепый вопрос для опытных профессионалов
    #36256099
baracs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvgЭто просто эмоции - количественных критериев нет. Без количественных критериев любая реально используемая база - помойка (вряд ли можно найти базу без хотя-бы одной ошибки).
Так по-жизни, зачастую, именно эмоции затарханного накладками из-за ошибок в БД начальства и являются критерием...
alexeyvgВряд-ли есть хоть одна реально используемая система с упомянутой мной бизнес-лигикой ввода фио (мной - как шутки, вами - серьёзно).
Вами - да уж
alexeyvgКонечно, если не брать специальные системы, для которых важно вести справочники ф. и. о. отдельно.
А почему, собственно, их не брать?
Назначение системы, с обсуждения которой начинался топик, автором старательно замалчивается...
...
Рейтинг: 0 / 0
Ещё более нелепый вопрос для опытных профессионалов
    #36256130
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
baracsalexeyvgКонечно, если не брать специальные системы, для которых важно вести справочники ф. и. о. отдельно.
А почему, собственно, их не брать?
Назначение системы, с обсуждения которой начинался топик, автором старательно замалчивается...Автор ветки написал:MicrobitПредметная область не предполагает лингвистический анализ имен и фамилий :) То есть таким образом описываются обычные клиенты - физические лица.Т.е. типа торговой системы, к примеру.

Хотя, конечно, про предметную область нужно точнее узнать.
...
Рейтинг: 0 / 0
Ещё более нелепый вопрос для опытных профессионалов
    #36256417
Microbit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
baracsНазначение системы, с обсуждения которой начинался топик, автором старательно замалчивается...
Вас что, интересует какие именно товары/услуги продает коммерческая организация своим клиентам - физическим лицам? Это что-то может изменить применительно к обозначенному вопросу? Скажем если продажа картин - это одно, а если химчистка белья - совсем другое?
...
Рейтинг: 0 / 0
Ещё более нелепый вопрос для опытных профессионалов
    #36256433
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MicrobitbaracsНазначение системы, с обсуждения которой начинался топик, автором старательно замалчивается...
Вас что, интересует какие именно товары/услуги продает коммерческая организация своим клиентам - физическим лицам? Это что-то может изменить применительно к обозначенному вопросу? Скажем если продажа картин - это одно, а если химчистка белья - совсем другое?Из описания не видно было, что это относится к продажам.
...
Рейтинг: 0 / 0
Ещё более нелепый вопрос для опытных профессионалов
    #36257814
muk07
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В одной знакомой БД есть фамилия НЕЕШЬПАПА.
И имя вот такое есть: Мухаббат кызы.
Слабо поместить в справочник.
...
Рейтинг: 0 / 0
Ещё более нелепый вопрос для опытных профессионалов
    #36258069
VStrel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Видел я подоюную реализацию в жизни: справочник приборов разрезали на мелкие части, страна производитель, тип пробора, завод изготовитель, город и т.д.

В итоге половина приборов в базе была из несуществующих в природе комбинаций. Что съекономили? справочник сам стал меньше, но в таблице появилось несколько ключей вместо одного. И эти дополнительные ключи требуют намного больше места %) нежели дополнительные строки в справочнике.

На мой взгляд унитарные объекты нельзя резать на части. Если это человек - то понём должна быть одна запись, а не набор ссылок. Можно сделать справочник паспортов, но использовать его это абсурд. Не нужно искать глубину на мелком месте.

Если операторы не имеют право - то DBA целыми днями будут добавлять всё нове и новые фамилии, имена, отчества. Если имеют - ошибки будут такие же у всех, только их будет в 100 раз больше
Будет полно записей "Елена Иванович"

вместо такого
FirstName nvarchar(100),LastName nvarchar(100),PartName nvarchar(100)
такой вариант
idFirstname int,idLastName int,idPatrName int
несомненно даёт экономию места, вот только когда дело доходит до поиска - вам нужна будет вьюха с индексами - и вся экномия места сразу теряется.

справочник с полом - абсурд, поле с значением в 1 бит - тут меньше ничего нельзя придумать
Справочник может быть для отображения в интерфейсе - это да
Но делать отдельную таблицу где будут id и пол - это бред (сюда тогда можно будет притулить историю, кто и когда пол сменил)
...
Рейтинг: 0 / 0
Ещё более нелепый вопрос для опытных профессионалов
    #36259072
baracs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MicrobitВас что, интересует какие именно товары/услуги продает коммерческая организация своим клиентам - физическим лицам? Это что-то может изменить применительно к обозначенному вопросу? Скажем если продажа картин - это одно, а если химчистка белья - совсем другое?
Ни в коем случае не хочу вас обидеть,
но у меня есть ощущение, что ваши коллеги столь фундаментально подошли к решению задачи потому, что имеют более полное представление о ней (или о перспективах развития), чем вы. И закладываются на будущее.

Вот и в вашем примере:
прачечной вряд ли понадобится хранить паспортные данные клиентов, а продажа картин - это немного другая история. Особенно, если картины известные...
А уж про перечень почтовых отделений с их адресами, вообще молчу
...
Рейтинг: 0 / 0
Ещё более нелепый вопрос для опытных профессионалов
    #36259129
Last1Cmen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
по ИНН или паспорту :)
...
Рейтинг: 0 / 0
Ещё более нелепый вопрос для опытных профессионалов
    #36263480
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivА квартира №10 -- это одна и та же квартира, тут решение
наоборот, вполне закономерно и правильно
Довести до абсурда можно и это. Пример - ввод адресных данных из метрик типа паспорта, свидетельства о рождении и т.п. Если в паспорте указано место рождения как Пермская область Или Коми-Пермяцкий автономный округ - будьте добры так и указать, даже если они уже давно стали Пермским краем. То же с переименованиями населенных пунктов, улиц и т.п. Или вообще населенный пункт перестал существовать...
...
Рейтинг: 0 / 0
14 сообщений из 39, страница 2 из 2
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Ещё более нелепый вопрос для опытных профессионалов
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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