iBase.ru Forum

Добрый день.
Вот такой вот у меня вопрос:
Прочитал одну книжку... В ней автор настаивал давать имена полям таблиц по следующей схеме: имя таблицы+"_"+имя поля, якобы для того, что бы имена полей во всей базе были уникальны.
Что ж... попробовал я так работать - могу сказать что очень уж это неудобно, когда есть куча похожих по структуре таблиц, но выражающие разные сущности. Может быть эти неудобства потом себя оправдают? Но ведь мы почти никогда не обращаемся к к.-л. поля не указывая, о какой таблице идет речь...
Интересно, а что по этому поводу думаете Вы, уважаемые наши "подсказчики"?

с одной стороны - да. правильная методика разработки БД, это когда ВСЕ имена полей по предметной области находятся в одном "пуле", где не допускаются повторы. Затем, строится концептуальная модель БД, то есть определяются сущности, которые наполняются атрибутами (столбцами, полями) из этого общего пула. И уж потом автоматом генерится физическая модель.

в данном случае использовать префикс сущности перед именем столбца не получится, т.к. сущность, куда попадет столбец, на этапе "набора пула столбцов" еще неизвестна.

Причем, например, если есть столбец "номер телефона", то он определяется как домен, а затем под разными (!) именами столбцов добавляется в таблицы "клиенты", "отделы", "менеджеры" и т.п.

Но это теория, а на практике каждый выбирает то, как ему удобнее. То есть, я описал идеальный вариант, а даже с нормальными формами практика не рекомендует пытаться "достичь идеала".

Я бы советовал, если делаешь два столбца NAME в разных таблицах, то чтобы содержимое этого столбца было похожим по смыслу. Чаще всего это делают для суррогатных ключей таблиц (ID). То есть, если вдруг смысловое наполнение A.NAME и B.NAME отличаются, то лучше их действительно поименовать по разному, дабы потом не было путаницы в голове при написании или просмотре текста запросов.

Зачем параноидальная уникальность, есть же псевдонимы. Я вот практичести все запросы пишу с пседонимами, а если в запросе есть джойны то 100% с псевдонимами.

То есть, никаких подводных камней не должно встретиться?
Тогда гораздо удобнее использовать названия полей попроще... типа ID,NAME... ведь чаще всего эти поля имеют идентичный смысл в различных сущностях (таблицах).

Ivan_Pisarevsky писал(а):Зачем параноидальная уникальность, есть же псевдонимы. Я вот практичести все запросы пишу с пседонимами, а если в запросе есть джойны то 100% с псевдонимами.

Да... и все в общем-то так делают

Проста эта... кг/ам. Это я про книжку. Аффтар баз более чем с 20 таблицами не видал.

Merlin писал(а):Проста эта... кг/ам. Это я про книжку. Аффтар баз более чем с 20 таблицами не видал.

Вот и я пришел к такому же мнению...
А теперь вопрос по существу... Как переименовать поле, на которое есть первичный или внешний ключ?
Что-то сервер не дает мне это сделать

Я вот практичести все запросы пишу с пседонимами, а если в запросе есть джойны то 100% с псевдонимами.

с псевдонимами ИМЕН СТОЛБЦОВ?

kdv писал(а):

Я вот практичести все запросы пишу с пседонимами, а если в запросе есть джойны то 100% с псевдонимами.

с псевдонимами ИМЕН СТОЛБЦОВ?

По-моему Иван имел в виду локальные псевдонимы таблиц в SELECT

и при чем тут имена столбцов, и псевдонимы таблиц?
я тоже использую псевдонимы таблиц. но я говорил про имена столбцов.

Вестимо псевдонимы для имен таблиц
Просто когда в запросе хотя бы пара таблиц, всегда обращение к полю делаю как псевдоним.имя_поля и я всегда знаю откуда я в итоге получу данные и оптимизатору не надо ничего "домысливать".
А имя столбца должно быть просто читаемым и понимаемым, а не вида very_long_field_identificator1, very_long_field_identificator2 и тп...

kdv писал(а): Я бы советовал, если делаешь два столбца NAME в разных таблицах, то чтобы содержимое этого столбца было похожим по смыслу...

Хочу добавить, что это весьма удобно для справочных справочников (словарей), которые по структуре одинаковы. Например, если более 10 словарей имеют однотипную структуру вроде (ID, NAME_FULL, NAME_SHORT), то в клиентской программе легче и проще реализовать редактирование таких справочников. Да и составление запросов с использованием JOIN будет выглядеть логично.