авторВам никто никогда не говорил о существовании правил проектирования? Вы хотите, чтобы я изложил Вам свой вариант? ;)
Структура данных для системы документооборота и записной книжки проектируется по одним и тем же правилам. Переносимость - безусловно в такие правила входит. Неужели это новость для Вас с Вашим достаточным опытом?
Вы всерьез полагаете, что для всех систем одинаково важна переносимость? Если так, то вы сели в лужу (такое «мнение» легко рвется на тряпки). Если нет, зачем вообще тыкать переносимостью как главным аргументом в пользу весьма коротких имен. Да и переносимость-то у вас весьма строгая — между разными СУБД. Осмелюсь утверждать, что потребность в такой степень переносимости достаточно редка, чтобы о ней здесь стоило вообще упоминать, как о существенном факторе выбора системы именования таблиц в общем случае.
Теперь по поводу «новостей». Может это будет новостью для вас, но
проектирование структуры данных вообще не связано с системой именования объектов . То есть связано, но постольку, поскольку нужно выбрать хоть какие-то имена. Тем не менее, можно спроектировать одну и ту же структуру данных, но поименовать объекты миллионом разных способов. И мы здесь обсуждаем вроде бы правила именования, а не правила проектирования. У вас здесь налицо попытка увести разговор в другую область.
автор> Так прошу вас определиться, чем все же вызваны пресловутые 4 буквы (или 8
> или 32): принципом, соблюдаемым даже при отсутствии жестких ограничений,
> или все же самими ограничениями? Что первично?
Целесообразность.
И опять нет ответа на четко поставленный вопрос. И вы еще говорите о своем желании «выслушать аргументированные мнения и отвечать так же аргументировано». Так отвечайте по сути, а не отделывайтесь общими словами. Таких слов я вам еще целый воз предложу: «здравый смысл», «рациональность», «системный подход» и пр. Эти заклинания настолько же никем не оспариваются, насколько понимаются каждым по-своему. Попытка уйти от конкретного ответа, спрятавшись за словом «целесообразность» выдает нежелание «отвечать аргументировано».
Еще раз попробуйте ответить: вы всеми силами втискиваете названия таблиц в 4 (8 или 32) знака потому, что
(1) таковы ограничения вашей конкретной задачи (то есть не от хорошей жизни), или потому, что
(2) таково ваше представление об идеальной системе именования, даже при отсутствии ограничений.
Если (1), то не стоит даже заикаться об «идеальности» такого подхода, ибо он приемлем в весьма узких рамках систем с указанными ограничениями.
Если (2), то прекратите даже упоминать требования «переносимости», наличие ограничений длины и т.п. ибо все это предмет варианта (1).
Тем не менее, у вас все время мешается и первое, и второе. Это говорит о не очень четком понимании своей собственной позиции.
авторЕсть правила. Проще этим правилам следовать во всех проектах. Дешевле.
Только вот как же с вашей «целесообразностью»? Тут ей и не пахнет, ибо «целесообразность» это «сообразность цели», то есть выбор средств и методов решения задач только в контексте конкретной разработки, конкретного проекта.
автор> Да ну? У меня прям глаза раскрылись. Вообще, не надо отуплять разговор. Речь
> идет между прочим о принципе именования объектов, а не о принципе
> уникальности имени, с которым никто и не спорит.
Кто-то утверждал, что нет разницы между именами людей, файлов и объектов базы данных. Что-то мне подсказывает, что имена файлов и имена, фамилии (с отчествами, если угодно) людей - как бы сильно не уникальны.
Так вот, принцип именования объектов базы данных очень даже имеет отношение к уникальности имен. Связь не очевидна?
Опять отупляете разговор. Ясно же, что уникальность любого имени понимается в контексте его области видимости. Попробуйте дать файлам одинаковые имена в одной папке. С людьми пример похуже, но можно сказать и тут, что глупо называть детей в одной и то же семье одинаковыми именами. Так никто не делает (кроме идиотов). Так зачем прикидываться, будто вы не понимаете, о чем я говорю. А говорю я не об
уникальности/неуникальности имен, которая полагается очевидной, а о
принципе формирования этих имен. А в этом контексте имена таблиц принципиально не отличаются от, скажем, имен классов/объектов в программе. Так если все руководства по стилям программирования советуют выбирать «говорящие» имена (в том числе и с префиксами/суффиксами если надо), то не вижу причин перенести тот же подход в область БД. А вы такие причины видите? В чем (только не надо опять про уникальность, умоляю)?
Более того, есть масса опубликованных Database Naming Conventions. В них ничего не говорится о необходимости «кодировать» имена. Я могу подкрепить свою точку зрения ссылками, а вы?
http://www.ss64.com/orasyntax/naming.html
Типичные примеры имен из текста: APPLICATION_FUNCTIONS, APPLICATION_FUNCTION_ROLES
http://vyaskn.tripod.com/object_naming.htm%5D%7C>]http://vyaskn.tripod.com/object_naming.htm]|> http://vyaskn.tripod.com/object_naming.htm" TARGET="_blank">http://vyaskn.tripod.com/object_naming.htmПримеры из текста:
So, name your customer table as 'Customers'.
Name your order storage table as 'Orders'.
Name your error messages table as 'ErrorMessages'.
автор> А если в аналогичных ситуациях вижу переменную kzrm13, модуль Unit187 и
> таблицу T015, то не обойтись ни без комментариев, ни без документации.
Дружище, а кто сказал, что объекты базы данных должны иметь только и исключительно кодовые имена? Что им должно мешать одновременно иметь и смысловые имена, и кодовые? Какая-такая религия? ;)
А что мешает иметь только смысловые имена? Какая-такая религия? ;)
авторсистема кодовых имен имеет преимущества, трудно- или недостижимые другими системами именования объектов базы данных:
1. Позволяет использовать имена объектов заранее заданной длины;
2. Легко позволяет скрывать реализацию.
Первое не является прерогативой «непонятных» имен (кодовых).
Второе вообще экзотика. Может это кому-то и бывает нужно, но выносить это как существенное преимущество в общем случае недопустимо.
авторС помощью некоторых несложных приемов разработчик может одновременно поддерживать смысловые имена вместе с кодовыми, что незначительно усложняет разработку и сопровождение баз данных.
В общем случае, усложняет совершенно неоправданно. Разработка и поддержка больших систем и без того нелегка, поэтому усложнять ее дополнительно без веских причин не стоит.
авторЯ попросил Вас привести Ваши правила именования объектов базы данных с учетом ограничения длины имени в 32 символа. К сожалению, Вы оставили просьбу без внимания, ограничившись констатацией наличия таких правил. Утверждать и иметь - как бы разные вещи. Мне не очень понятно, как на это нужно реагировать? Как на отсутствие этих правил? Как нежелание ими делиться?
Вы невнимательно читаете мои ответы. Процитирую себя же: «Я использую MS SQL Server 2000, там можно использовать 128 символов. Тем не менее, система именования у нас есть. Если бы было ограничение в 32 или 8 или 4 символа в длине, была бы другая система, с более жесткими ограничениями.» Что тут непонятно? Перечитайте еще разок.
Где я вам обещал привести свои правила именования для длины в 32 знака ?
