Когда речь идет о написании кода, например на том или ином языке программирования , то в профессиональных командах разработчиков рано или поздно приходят к использованию единой нотации переменных , констант, классов , функций и так далее. Каждый разработчик понимает , для чего это нужно и следует принятым правилам и
соглашениям о кодировании, делая "хорошо" прежде всего самому себе.
Но когда заходит речь о проектировании и создании схем БД, то зачастую необходимость применения унифицированных принципов именования не всеми осознается и тем более не всеми применяется. Хотя в этом направлении стандартизированность не менее важна и не менее нужна...Не знаю , как на этот вопрос смотрят разработчики, но попытаюсь изложить взгляд со стороны тестирования...
По своему личному опыту могу точно утверждать, что единообразие наименований
объектов в БД очень часто существенно экономит время . Преимущественно речь идет о времени на написание SQL-запросов особенно, когда приходится их писать сотнями в день и когда имеешь дело с большой разветвленной БД, где десятки а иногда и сотни таблиц. В этом случае все названия запомнить , конечно же , нереально, но если ты заранее знаешь , что имеешь дело со словарной таблицей и у нее обязательно есть
mnemonic , и
description, то это существенно облегчает жизнь. Если же проектировщики и разработчики задумывали и создавали БД "кто в лес, кто по дрова", то ты заранее не знаешь,
description там или же
desc, а может
descr или вообще поле с опечаткой.. В итоге запрос с первого раза не пишется, надо смотреть описание таблицы - в общем, делать лишние движения. Они небольшие, но их много и вообще , как в песне поется, "не думай о секундах свысока"...
С экономией времени на составлении запросов вроде бы все ясно, потому что явно. Есть и другие менее явные положительные эффекты от единой стратегии именования.
Буквально на днях сталкивался с конкретной задачей автоматизации, которая решалась бы гораздо меньшими усилиями и существенно меньшим количеством строк кода, если бы не винегрет в названии одинаковых по смыслу полей в разных таблицах. То есть и в направлении автоматизации тестирования возможна экономия сил , нервов и средств при минимально едином подходе.
Еще один положительный эффект - новички ( и разработчики , и тестировщики ) гораздо быстрее осваивают систему, если при ее проектировании и разработке применяются единые правила наименований объектов. Быстрее осваивают - читай, быстрее начинают приносить реальную пользу.
В общем, везет тем , кто везет. А что делать если приходится работать с тем, что есть? Если , к примеру, схема БД росла и множилась годами, накопила кучу болячек, пережила не одну текучку кадров и к стандартизации нотации объектов в этой БД относились "с прохладцей"? Конечно же, не надо посыпать себе и тем более другим голову пеплом , не надо искать виноватых и жаловаться всем на всех.. Просто старайтесь конструктивно доводить до ответственных лиц необходимость
рефакторинга схемы БД , если такого осознания у них нет. Если же это осознание уже есть, то готовьте тесты , проверяющие, что в результате рефакторинга система дает конечному пользователю как минимум то же самое, что и до него ))
Полезная информация по теме:
[1] Форумы на sql.ru - искать по "
правила именования объектов базы данных" - тут знающий народ, решающий реальные задачи. Много хороших и дельных советов и практик.
[2] Хорошая книга как раз о рефакторинге уже существующей БД:
Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series)
Scott W. Ambler, Pramodkumar J. Sadalage
