Просто и «по-американски» о разработке БД
Источник: Complexity (968) вы можете увидеть форму, содержащую лист-бокс с возможностью редактирования по месту, которая изменяет свой размер.
А теперь следующее правило:
Правило 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