Пять правил разработки программ

Просто и «по-американски» о разработке БД

Источник: Complexity (436) вы можете увидеть форму, содержащую лист-бокс с возможностью редактирования по месту, которая изменяет свой размер.
А теперь следующее правило:

Правило 2

ИЗБЕГАЙТЕ ИЗБЫТОЧНЫХ ДАННЫХ

Для рассмотрения этого правила я придумал простой пример. Вова пишет программу для гаража. Это большой гараж, в нем работает много механиков. И Вова хочет отслеживать  кто из них наиболее опытен для определенного вида работ. Вова решил, что ему нужна таблица, что то вроде:

Mechanic Table         Таблица Механиков
--------------         -----------------
NameMechanic           Имя механика
DateBirth              Дата рождения
Passport               Номер паспорта
RateHourly             Ставка за час
Skill                  Умение (или специализация)

Но конечно же один механик может иметь больше, чем одну специализацию. Общее решение — повторить записи о механике столько раз, сколько у него специализаций. Но теперь Ася Булкина выходит замуж. Для нее в таблице
заведено 241 запись, и кто-то должен просмотреть все эти записи и в каждой исправить ее фамилию на новую. Хотя … для чего нужны секретари? 🙂
Вова подумал и решил сделать таблицу так:

Mechanic Table
---------------
NameMechanic DateBirth SocialSecurity RateHourly
Skill1 Level1 Skill2 Level2 Skill3 Level3 Skill4 Level4

но помня о первом правиле, которое говорит о том, что нужно избегать такого положения вещей, Вова сделал две таблицы:

MechanicTable              SkillTable (таблица навыков)
------------               -----------
NameMechanic               NameMechanic
DateBirth                  Skill
Passport                   Level
RateHourly

теперь для каждого механика есть таблица его навыков. Это выглядит хорошо за исключением того момента, что если понадобится сделать
поиск «Какие люди владеют навыком», то его невозможно будет сделать. Потому что кто-то введет в поле специализация «Регулировка установки колес» для одного мастера, другой
«Регулировка» для другого мастера, а для третьего «Рег. колес». Конечно можно выписать все наименования на стикер и прилепить к монитору, но … елы палы … на дворе 21 век.
Ты можешь сделать лучше Вова. Сделай таблицу «Список специализаций», которую можно будет поместить
на форму как выпадающий список (drop down). Т.е. теперь структура таблиц будет следующей:

MechanicTable              MechanicSkillTable                SkillTable
(таблица механиков)        (таблица навыков механика)        (таблица специализаций)
------------               ---------------------------       ------------------------
NameMechanic ------------> NameMechanic
DateBirth                  Skill  в таблице MechanicSkillTable изменятся имена. И теперь, если снова зайти в форму, то все навыки Аси Батоновой будут на своем месте.
Пользователю такой вариант явно не понравится. Что же делать Вове?
Посмотрите внимательно на таблицу MechanicSkillTable. Таблица представляет из себя
список имен механиков и имен специализации. Но эти наименования не несут в себе особо смысла. Можно сказать так "у этого механика есть такой то навык". Т.е. без разницы
у какого механика и какой навык. И теперь вступает в силу второе правило. Цель второго правила не состоит в уменьшение количества хранимой информации, его цель
сделать обновления эффективным и без всяких сюрпризов. Я немного подкорректировал таблицы, созданные Вовой:
MechanicTable              MechanicSkillTable                SkillTable
(таблица механиков)        (таблица навыков механика)        (таблица специализаций)
------------               ---------------------------       ------------------------
SysIDMechanic -----------> SysIDMechanic
NameMechanic               SysIDSkill