guest_20040621
> Вы всерьез полагаете, что для всех систем одинаково важна переносимость?
Нет, не одинаково важна. Для одних проектов - это краеугольная штука, для других - факультативная.

Наконец-то вы признаете свои ошибки.

guest_20040621
> Осмелюсь утверждать, что потребность в такой степень переносимости
> достаточно редка, чтобы о ней здесь стоило вообще упоминать, как о
> существенном факторе выбора системы именования таблиц в общем случае.
Позвольте с Вами не согласиться.

Позвольте с Вами не согласиться.

guest_20040621
Так мы не до чего не договоримся. Проектирование баз данных - суть набор правил. В том числе и именования. Если Вы так не считаете, дискуссия смысла не имеет.

Увы, у вас довольно примитивное, плоское представление о проектировании вообще и проектировании БД в частности. Без обид.
Во-первых, проектирование — это не набор правил, а процесс преобразования внешних требований к системе во внутренние требования к ее фактическому устройству и функционированию. Если еще шире, то проектирование есть моделирование несуществующей системы в условиях известных ограничений. Да, проектирование основано на ряде правил, подходов и технологий. Первое ваше заблуждение в предположении, что есть полный комплект универсальных правил, подходящих для всех систем на все времена. Это не так. Если бы они были, не было бы множества разных технологий и методов, не было бы постоянных споров корифеев о том, что лучше и как правильней. Еще Брукс сказал: нет серебряной пули.
Второе ваше заблуждение в предположении о равноправии всех правил и составляющих проектирования. Дело в том, что есть проектные решения важные и маловажные. По терминологии Буча есть проектирование в большом и проектирование в малом. По терминологии RUP есть архитектурно-значимые решения и архитектурно-незначимые решения. По терминологии ЕСПД есть эскизный проект и технический проект. Разница иногда зыбкая (как и все в этой жизни), но она есть. И если вы не понимаете этой разницы, то говорить воистину не о чем. А истина в том, что в 99% случаев проект структуры данных ИС относится скорее к архитектурно-значимым частям проекта, а вот стиль кодирования, стиль именования объектов в лучшем случае к архитектурно-незначимым, а в худшем это вообще не предмет проектирования, а предмет поддерживающих процессов разработки.

guest_20040621
> И опять нет ответа на четко поставленный вопрос.
К сожалению, я не нашел более подходящего слова. Подробнее - долго и imho не интересно.

Да, выбор одного варианта ответа из двух возможных — это очень долго и очень неинтересно.

guest_20040621
Поверьте, эти рамки гораздо шире, чем Вы полагаете. ;)

Поверьте, эти рамки гораздо уже, чем Вы полагаете. ;)

guest_20040621
донести до Вас я пытаюсь совершенно тривиальную мысль: есть правила проектирования, отличные от используемых Вами. Они чуть шире, гораздо более гибки и на порядок универсальнее.

Степень Вашего понимания правил проектирования я уже уяснил.

guest_20040621
Помните анекдот про бармена и проверяющего? Когда бармен проверяющему регулярно недоливал и на замечание отреагировал: "Да мне проще штраф заплатить, чем руку сбивать".

А вот это очень точное замечание, которое говорит о вашем подходе больше, чем вы полагаете. Бармен настолько привык делать нехорошую вещь, что не может и не хочет перестроится, даже если это необходимо. Да, гибкостью подхода здесь и не пахнет.

guest_20040621
;) Дружище, мы несколько по-разному относимся к проектированию. Просто поверьте на слово: нужно. Очень нужно.

О да, по разному. И поверьте мне на слово: в большинстве случаев не нужно. Совсем не нужно.

За сим откланиваюсь и больше участия в этой дискуссии не принимаю.