Comments 22
все правильно, очень хорошие советы.
касательно «Ведь мы же не можем заранее заполнить столбцы “Дата смерти” или “Дата увольнения”, мы же не предсказатели тыкать пальцем в небо :-).» — такая рекомендация пройдет только если мы делаем базу данных для морга где ожидается что все люди мертвы (с единичными исключениями когда дата неизвестна).
в остальных случаях, если база не мертвых и не уволенных людей, то лучше это моделировать в представлении (view) как вычисляемое поле.
касательно «Ведь мы же не можем заранее заполнить столбцы “Дата смерти” или “Дата увольнения”, мы же не предсказатели тыкать пальцем в небо :-).» — такая рекомендация пройдет только если мы делаем базу данных для морга где ожидается что все люди мертвы (с единичными исключениями когда дата неизвестна).
в остальных случаях, если база не мертвых и не уволенных людей, то лучше это моделировать в представлении (view) как вычисляемое поле.
Эм… а из чего его вычислять, если под это нет полей? )
полей нет, зато есть таблицы ))
например для увольнения есть таблица приказов/заявлений
для смерти — другая таблица.
я имел в виду, что добавляя столбец например дата смерти мы гарантируем что почти у всех значения будут NULL (мы же не базу мертвецов строим, ведь?) и только у единиц будут значения, а SQL движки плохо работают с разреженными столбцами где много NULL и мало значений.
правильнее будет нормализовать дальше и сделать таблицы (Сотрудники, Приказы)
например для увольнения есть таблица приказов/заявлений
для смерти — другая таблица.
я имел в виду, что добавляя столбец например дата смерти мы гарантируем что почти у всех значения будут NULL (мы же не базу мертвецов строим, ведь?) и только у единиц будут значения, а SQL движки плохо работают с разреженными столбцами где много NULL и мало значений.
правильнее будет нормализовать дальше и сделать таблицы (Сотрудники, Приказы)
т.е. вьюха «сотрудник» будет постоянно лазать в приказы? причём выбирая по дате, типу документа и неизвестно чему ещё, особенно если приказы ведутся в другой системе?
В этом плане иногда лучше денормализовать, чем делать сотню джоинов.
Так можно дойти и до того что таблица «сотрудник» не нужна. Можно собрать из документов, остатки — из проводок итп-итп.
Что значит «плохо работают»? Вы собрались индексировать этот столбец? Зачем? )
В этом плане иногда лучше денормализовать, чем делать сотню джоинов.
Так можно дойти и до того что таблица «сотрудник» не нужна. Можно собрать из документов, остатки — из проводок итп-итп.
Что значит «плохо работают»? Вы собрались индексировать этот столбец? Зачем? )
мы же не базу мертвецов строим, ведь?Если у вас вообще как-то фигурирует слово «смерть» в ТЗ, то да, мы строим базу мертвецов. Например, БД ЗАГСа будет такой базой. Вы же не думаете, что в момент смерти данные по человеку тупо удаляются из БД?
полей нет, зато есть таблицы ))Целую таблицу под смерти? Слишком дофига. Для разовых событий (типа рождения и смерти) вполне достаточно просто одного поля с соответсвующим событием. А вот под документальное сопровождение этих процессов уже можно нагородить таблиц (например, человек может быть признан мертвым, потом найтись живым, а то и несколько раз так, но в итоге рано или поздно он умрет окончательно, и на каждый такой случай будет решение уполномоченного органа — полиции, больницы, суда и т. д., а на каждое решение — запись в базе).
например для увольнения есть таблица приказов/заявлений
для смерти — другая таблица.
В.банковских системах такое поле встречается, т.к. есть законодательство о наследстве и эта дата реально нужна…
Ввиду особенностей людей она может называется не совсем корректно, что может привести к путанице...
>>>Для разовых событий (типа рождения и смерти) вполне достаточно просто одного поля с соответсвующим событием. А вот под документальное сопровождение этих процессов уже можно нагородить таблиц
вы только что подтвердили, что я прав. под документальное сопровождение данные нормализуются, а вот ваш «один столбец в таблице» это лишь один вычисляемый столбец в материализованном представлении
вы только что подтвердили, что я прав. под документальное сопровождение данные нормализуются, а вот ваш «один столбец в таблице» это лишь один вычисляемый столбец в материализованном представлении
А почему нельзя в основной таблице (Сотрудники) сделать boolean поле dead/fired? А всю информацию о смертях/увольнениях (дата, № свидетельства о смерти/приказа об увольнении и т.д.) хранить в отдельной таблице. Т.к. информация по мертвым/уволенным скорее всего нечасто нужна будет.
Потому что:
1. Поддержка историчности. Если надо состояние сотрудника на дату — то хорошо бы знать не просто факт его смерти на текущий момент, а дату смерти/увольнения.
2. Что бы не лазать за датой далеко-далеко, а её обычно хотят знать.
3. Если есть записи типа «уволен — принят» потом опять «уволен — принят», к примеру, при смене подразделений или должностей.
1. Поддержка историчности. Если надо состояние сотрудника на дату — то хорошо бы знать не просто факт его смерти на текущий момент, а дату смерти/увольнения.
2. Что бы не лазать за датой далеко-далеко, а её обычно хотят знать.
3. Если есть записи типа «уволен — принят» потом опять «уволен — принят», к примеру, при смене подразделений или должностей.
Я исхожу из того, что бОльшая часть запросов будет относиться к действующим сотрудникам.
Выбирать действующих сотрудников по условию уволен=false мне кажется более безопасным, чем по условию дата_увольнения=NULL.
И да, для одного сотрудника действительно может быть несколько записей «уволен-принят». Т.е. между сотрудником и датами приема/увольнения связь один-ко-многим, соответственно — даты приема/увольнения нужно в отдельной таблице хранить.
Выбирать действующих сотрудников по условию уволен=false мне кажется более безопасным, чем по условию дата_увольнения=NULL.
И да, для одного сотрудника действительно может быть несколько записей «уволен-принят». Т.е. между сотрудником и датами приема/увольнения связь один-ко-многим, соответственно — даты приема/увольнения нужно в отдельной таблице хранить.
в учете кадров все намного сложнее, потому что сотрудник может быть уволен но начиная с даты в будущем (например с 1 ноября).
Любые флаги и состояния имеют дату, когда они вступают в эффект.
поэтому одним булевским полем не обойтись, тут нужна максимальная нормализация
Любые флаги и состояния имеют дату, когда они вступают в эффект.
поэтому одним булевским полем не обойтись, тут нужна максимальная нормализация
Ну да, большая часть запросов будет к действующим сотрудникам. К действующим сотрудникам на дату. На прошлый понедельник, на прошлый отчётный квартал или на завтра.
В случае если сотрудник уволен-принят чаще всего его заводят как нового сотрудника, к сожалению.
В случае если сотрудник уволен-принят чаще всего его заводят как нового сотрудника, к сожалению.
Есть 6 нормальных форм и шестая как раз с той самой избыточностью
Статья — редкостный бред. Неправильно почти каждое предложение. Такое ощущение, что автор базы данных видел только в детском саду в книжке-раскраске.
Первые два пункта — просто вода, можно сразу заменить на "делайте хорошо и не делайте плохо".
А дальше вода кончается, и начинаются перлы.
Как мы уже ранее говорили, от назначения базы данных зависит, какие методы использовать при моделировании.Методы моделирования совершенно не зависят от назначения БД.
Если мы проектируем базу данных для оперативной обработки записей (OLTP), иными словами для их создания, редактирования и удаления, то используем моделирование транзакций. Если же база данных должна быть реляционной, то лучше всего применять многомерное моделирование.Как сие понимать? База может быть либо OLTP, либо реляционной??? Конечно же нет, база очень легко может быть и OLTP, и реляционной одновременно. OLTP обычно противопоставляется OLAP'у, но тут и выбирать особо нечего: если знать, что каждая из аббревиатур означает, перепутать их друг с другом практически невозможно.
используем моделирование транзакцийМоделирование транзакций — это что за зверь? Что там моделировать??? За 12 лет в IT ни разу не слышал ничего подобного.
Во время моделирования строятся концептуальные (CDM), физические (PDM) и логические (LDM) модели данных.Эти модели строятся разве что диванными теоретиками. На практике обычной ER-диаграммы более чем достаточно.
Если же сущность ведет собственную жизнь, имеет атрибуты, которые описывают ее поведение и ее вид, а также отношения с другими объектами, то смело можно использовать не только подтип, но и супертип ( родительская сущность).Совершенно непонятно, о каких БД вы говорите в статье. Вроде бы в одних местах говорите не только о реляционных, но зачем-то в других местах употребляете термины, относящиеся только к реляционной модели, не уточняя, что имеете в виду именно ее, а где-то говорите о вещах, к реляционной модели не относящихся вообще. Лучшего способа запутать читателя не придумаешь. Этот кусок, например, — он о чем вообще?
Лучше всего использовать естественный, или бизнес, ключ (natural key). Он имеет смысловое значение, так вы избежите дублирования в базе данных.Лучше, конечно, не использовать. Натуральные ключи иногда состоят из нескольких полей, и написание джойнов превращается в ад.
Если только бизнес-ключ не уникаленЕсли ключ не уникален, то он не ключ. Ваш Кэп.
Существует пять нормальных форм, которым нужно следовать.Во-первых, не пять (но тут как считать, и вообще, это неважно), во-вторых, не «нужно», а «можно», и в большинстве случаев работает правило «бери третью — не ошибешься».
Лучше всего тестировать базу данных путем Continuous Integration (непрерывной интеграции).Continuous Integration, конечно, включает в себя тестирование в качестве одного из основных этапов, но в целом это не про тестирование.
В общем, статья — отличная антиреклама для курсов. Ни за что никому не порекомендую курсы, которые таким образом рекламируются.
Гм, разверните пожалуйста мысль, почему использование NULL — однозначно плохо, а пустой строки — нормальное приемлемое решение?
Для строк, позволяющих NULL, сравнения сложнее, и, бывает, мешают использованию индексов.
Допустим, вам нужно найти все строки, не начинающиеся со слова «тест».
Если строка не позволяет NULL, то поиск будет через условие value not like 'тест%', если позволяет, то такое условие не выдаст вам null-овые строки, поэтому нужно писать либо isnull(value, '') not like 'тест%', либо value not like 'тест%' or value is null.
Вариант без NULL будет использовать поиск по индексу.
Первый вариант с NULL — полный скан индекса, применение к каждой строке функции, и только потом фильтрацию.
Второй вариант с NULL возможно развернется оптимизатором в два поиска по индексу, а возможно и нет… И даже если развернется — два поиска это дольше, чем один.
Допустим, вам нужно найти все строки, не начинающиеся со слова «тест».
Если строка не позволяет NULL, то поиск будет через условие value not like 'тест%', если позволяет, то такое условие не выдаст вам null-овые строки, поэтому нужно писать либо isnull(value, '') not like 'тест%', либо value not like 'тест%' or value is null.
Вариант без NULL будет использовать поиск по индексу.
Первый вариант с NULL — полный скан индекса, применение к каждой строке функции, и только потом фильтрацию.
Второй вариант с NULL возможно развернется оптимизатором в два поиска по индексу, а возможно и нет… И даже если развернется — два поиска это дольше, чем один.
"Если же база данных должна быть реляционной, то лучше всего применять многомерное моделирование."
Это о чём?
Интересно — а для кого статья?
И что полезного для реального мира проектирования Баз Данных, читатель после должен вынести?
Хотя, это от риторические вопросы, конечно.
Sign up to leave a comment.
Проектирование Базы Данных. Лучшие практики