Название поля первичного ключа.

← →
Дмитрий С © (2012-12-23 14:07) [0]

Предположим таблица новостей `new`.
Как лучше назвать поле PK:
id или new_id ?

← →
Медвежонок Пятачок © (2012-12-23 14:14) [1]

create table dat_news(
dn_id number not null, primary key,
...
);

← →
Юрий Зотов © (2012-12-23 14:31) [2]

ИмяПоля - поле таблицы.
ИмяТаблицы_ИмяПоля - внешняя ссылка на это поле.

← →
Юрий Зотов © (2012-12-23 14:42) [3]

Эта система наименований полей удобна тем, что по имени поля таблицы сразу ясно, куда оно ссылается, или не ссылается никуда.

← →
Дмитрий С © (2012-12-23 16:34) [4]

> create table dat_news(
> dn_id number not null, primary key,
> ...
> );

Во-первых можно получить одинаковые аббревиатуры, во-вторых получаем еще одно лишнее имя.

> ИмяПоля - поле таблицы.
> ИмяТаблицы_ИмяПоля - внешняя ссылка на это поле.
>
>

это получается
id в таблице new
и new_id в ссылающихся таблицах?
У меня так и сделано, но смущает, что у MySQL есть упрощенный синтаксис join-а:
FROM new JOIN <table> USING (new_id)
Но в обеих таблицах должно быть поле new_id . Не спроста же есть такой синтаксис.

← →
Медвежонок Пятачок © (2012-12-23 17:02) [5]

Во-первых можно получить одинаковые аббревиатуры, во-вторых получаем еще одно лишнее имя.

Можно и получить. Если стараться.
Я не получаю.
Лишних имен у меня нет.

← →
Игорь Шевченко © (2012-12-23 17:35) [6]

> Предположим таблица новостей `new`.

плохое предположение, таблица новостей должна иметь имя news.
и да, имена полей в таблице не должны дублировать ее имя.

> Не спроста же есть такой синтаксис.

у MySQL все не так, как у людей

← →
Аббат Пиккола (2012-12-24 12:21) [7]

Как лучше назвать поле PK:
id или new_id ?

Я сотни раз делал и так и так.
Могу сказать, что есть некоторое преимущество у того чтобы назвать new_id но с одной оговоркой. Все ссылки из других таблиц на это порле также должны называться new_id, а не имя_другой_табицы_new_id

Для целей автоматической нормализации case-средства часто используют подход, сводящийся к тому, чтобы поле называлось таблица_поле и все внешние ссылки на него тоже назывались таблица_поле.

Например

user_id
user_name

article_id
article_name
user_id это - id автора статьи. то есть ссылка на PK таблицы user

Дело в том, что user_id это совершенно определенное понятие и ВО ВСЕХ таблицах оно будет означать одно и то же - id пользователя. И во всех таблицах одинаково называться.

Неверно говорить "лучше называть имя таблиы_имя поля".
верно говорить "лучше называть имя_сущности_имя_атрибута".
Тогда все встанет на свои места.

Если имеется такая сущность:

user_id
user_name
article_id
article_name

То при автоматической нормализации CASE-средство выделит сущность acrticle в отдельную таблицу и организует внешний ключ на таблицу user_id после того как получит ответ на вопрос как соотносятся сущности user и article (ответ один user ко многим article).

← →
Ega23 © (2012-12-24 12:31) [8]

Делал тремя различными способами.
Разницы никакой, главное, чтобы остальные члены команды понимали.

← →
Аббат Пиккола (2012-12-24 12:48) [9]

Абстрагируемся от того, хорошо ли название NEW для таблицы. Или лучше NEWS. На английском новость (одна) - тоже NEWS.

Но во всех остальных случаях я лично предпочитаю называть сущность в единственном числе, а не во множественном (BOOK - таблица, в которой лежат книги). Допустим у меня имеется таблица с книгами и таблица с авторами и таблица издателей.

BOOK
------------
BOOK_ID
BOOK_NAME
BOOK_YEAR
AUTHOR_ID
PUBLISHER_ID

AUTHOR
-----------
AUTHOR_ID
AUTHOR_NAME

PUBLISHER
-------------
PUBLISHER_ID
PUBLISHER_NAME

Это - самый строгий вариант.
Но возможен и упрощенный вариант, если я не собираюсь использовать какие-либо средства автоматической нормализации и хочу максимума лаконичности:

BOOK
------------
ID
NAME
AYEAR
AUTHOR_ID
PUBLISHER_ID

AUTHOR
-----------
ID
NAME

PUBLISHER
-------------
ID
NAME

При таком (лаконичном) подходе я именую сами констрейнты:

PK_BOOK_ID
PK_AUTHOR_ID
PK_PBLISHER_ID
FK_BOOK_AUTHOR_ID
FK_BOOK_PUBLISHER_ID

И получается все максимально лаконично и все названия констрейнтов получаются заведомо уникальными.

Но за много лет я так и не выбрал для себя какой-то из этих двух стилей как единственно верный. Хотя склоняюсь ко второму (хотя и реже им пользуюсь). В нем сразу заметны атрибуты иных сущностей в таблице. А в "лаконичном" - не сразу заметны. Так как в строгом варианте всякий атрибут, не начинающейся с имени сущности (префикса) выдает себя "я чужой", а в лаконичом варианте нужно обращать внимание на суффикс _ID, что требует больше внимания, так как префиксы видны лучше, чем суффиксы и сазу бросаются в глаза.

← →
Аббат Пиккола (2012-12-24 13:00) [10]

Ega23 © (24.12.12 12:31) [8]

Согласен.

Могу предложить еще один подход, сочетающий лаконичность и строгость.

Только ключевые поля (как первичные, так и внешние) содержат префикс "сущность". Все остальные поля называем лаконично.

Тогда все выглядит так:

AUTHOR
--------
author_id
name

PUBLISHER
----------
publisher_id
name

BOOK
----------
book_id
name
ayear
author_id
publisher_id

← →
wl © (2012-12-24 13:01) [11]

есть же ветка "Базы", зачем это в прочем то помещать?

← →
Jeer © (2012-12-24 13:03) [12]

TableName_FieldName
Пришел к такому варианту давно, перепробовав и ручные и case-подходы.

Избегать использования ключевых слов в именах таблиц и полей следует всегда.

← →
Toha_Nik (2012-12-24 13:08) [13]

> Ega23 © (24.12.12 12:31) [8]

точно, главное что PK и FK

← →
знайка (2012-12-24 13:18) [14]

UserId, NewsId...

← →
MsGuns © (2012-12-24 13:20) [15]

ИМХО, самое простая и понятная система:

1) RN/ID - собственно идентификатор, PRN/PID - ссылки на узлы (главные записи - FK), FRN/FID - ссылки на словари (ссылочные записи - FK)

2) При составлении запросов перед именем поля ВСЕГДА ставится имя таблицы/алиас

3) При создании таблицы (скрипт CREATE) ОБЯЗАТЕЛЬНО присутствует сотв. комментарий

4) Как альтернативный вариант - замена доступных клиенту селектов вьюхами, где имена возвращаемых колонок не зависят от физ.таблиц, которые делаются недоступными пользователю НЕПОСРЕДСТВЕННО.

Использование имен ссылочных таблиц в именах полей приводит к загромождению скл-запросов лишними "букавами", что делает их чтение весьма затруднительным

← →
Дмитрий С © (2012-12-24 13:20) [16]

А как быть с двойными ссылками?
Допустим таблица тем форума: thread, у нее помимо прочих два поля: "автор темы", "автор последнего сообщения". Оба поля не назовешь же user_id. Как тут быть?

← →
Медвежонок Пятачок © (2012-12-24 13:22) [17]

Как тут быть?

неужели придется дать разные имена?

← →
Аббат Пиккола (2012-12-24 13:35) [18]

Аргумент в пользу того, чтобы назвать поле AUTHOR_ID как в таблице AUTHOR, так и в таблице BOOK, если мы используем Delphi для работы с таблицами.

Допустим я использую каких-то наследников от TDataSet и организую два редактируемых результата запроса на форме в отношении главный-подчиненный

Query1
SELECT AUTHOR_ID, NAME FROM AUTHOR

Query2
SELECT BOOK_ID, NAME, AUTHOR_ID FROM BOOK
WHERE AUTHOR_ID = :AUTHOR_ID

и DataSource1

И такие еще связи между компонентами
DataSource1.DataSet := Query1;
Query2.DataSource := DataSource1;

При таком подходе удобнее иметь сразу поле AUTHOR_ID, а не неопределенное ID. Так как манера называть поля ID без префикса приведет к такому запросу:

Query2
SELECT ID, NAME, AUTHOR_ID FROM BOOK
WHERE AUTHOR_ID = :ID

Или же в первом запросе придется заюзать алиас AUTHOR_ID для поля ID, чтобы избежать проблем. Так не лучше ли с самого начала иметь такое название для поля?

← →
Аббат Пиккола (2012-12-24 13:37) [19]

2 Дмитрий С © (24.12.12 13:20) [16]
А как быть с двойными ссылками?

Хороший вопрос

← →
Ega23 © (2012-12-24 13:39) [20]

Лично сейчас остановился на id для PK, Имя_Сущности + id для FK.

Т.е.
create table master ( id..., ....., constraint pk_master primary key (id) ) create table detail ( id, masterid, lastmasterid, ..... constraint pk_detail ... (id) constraint fk_detail_ref_master constraint fk_detail_refmaster_2 )

Поиск вторичного ключа по имени - честное слово, я не припомню, чтобы такая задача в практике возникала. А так - всегда можно посмотреть, кто там на что ссылается. Поэтому последующие ключи таблицы Detail на таблицу Master - смело нумеровать, как 2, 3, ... N

← →
Ega23 © (2012-12-24 13:41) [21]

> При таком подходе удобнее иметь сразу поле AUTHOR_ID, а
> не неопределенное ID. Так как манера называть поля ID без
> префикса приведет к такому запросу:

При таком подходе тебе никто не мешает сделать select id as authorid from authors
Или ваще использовать вьюхи.

← →
Аббат Пиккола (2012-12-24 13:41) [22]

Эти случаи составляют редкость, пожэтому я обычно как-то выкручиваюсь. То есть отклоняюсь от общей системы наименований. Вместо user_id использую theme_author_id, last_message_author_id. Если это РЕДКОСТЬ, то можно поозволить себе ИСКЛЮЧЕНИЕ. Если же таких вещей уйма, ито буду искать какое-то подходящее решение, возможно отклонюсь от своих обычных привычек.

← →
Аббат Пиккола (2012-12-24 13:43) [23]

2 Ega23 © (24.12.12 13:41) [21]

Я так и поступаю. Я склоняюсь в полной лаконичности (использую ID), Но всякий раз приходится применять алиасы, поэтому часто сожалею, что не использовал префикс. В общем колебания у меня остаются, хотя привычка не использовать префиксы слишком сильна.

← →
Аббат Пиккола (2012-12-24 13:48) [24]

Обсуждение показывает, что нет какого-то одного единственно правильного решения. Более того, одни и те же люди используют то один подход, то другой.

← →
MsGuns © (2012-12-24 13:57) [25]

Вот пример далеко не самого большого запроса, оформленного "по правилам".
Разбирать его - все равно что искать монетки в куче навоза :)

const AnsiString SQL_ORACLE_SELECT_ASTRA_REESTR_OUT1 = \
"SELECT temp_nalog.obor_date, \
temp_nalog.cez_id, \
CASE WHEN temp_nalog.cez_id IS NULL THEN 1 ELSE 0 END ntk_id, \
temp_nalog.provider_id, \
temp_nalog.provider_taxdoc, \
temp_nalog.provider_taxnum, \
temp_nalog.provider_name, \
temp_nalog.personal_count, \
temp_nalog.abonstatus_id, \
temp_nalog.abon_name, \
DECODE(nvl(temp_nalog.taxpayer_type, 1), 1, \
decode(trim(temp_nalog.tax_num), "не платник", "0", trim(temp_nalog.tax_doc)), \
"0") tax_doc, \
DECODE(nvl(temp_nalog.taxpayer_type, 1), 1, \
decode(trim(temp_nalog.tax_num), "не платник", "0", trim(temp_nalog.tax_num)), \
"0") tax_num, \
temp_nalog.nalog_num, \
temp_nalog.nalog_series, \
temp_nalog.nalog_date, \
temp_nalog.nalog_num_old, \
temp_nalog.nalog_series_old, \
temp_nalog.nalog_date_old, \
temp_nalog.obor_date_calc, \
temp_nalog.formtype_id, \
nvl(temp_nalog.taxpayer_type, 1) taxpayer_type, \
temp_nalog.is_correction, \
temp_nalog.status, \
temp_nalog.codification_code, \
"0" || decode(temp_nalog.ndstype_id, 4, 2, temp_nalog.is_correction) || decode(temp_nalog.ndstype_id * temp_nalog.is_correction, 4, 2, abs(temp_nalog.status)) nalog_type, \
case when trim(temp_nalog.tax_num) = :tn \
then "ЗЦ" \
when temp_nalog.ndstype_id = 4 \
then "БО" \
when temp_nalog.is_correction = 1 \
then "РК" \
else "ПН" \
end || \
case when temp_nalog.ndstype_id = 4 \
then "" \
when temp_nalog.formtype_id = 2 \
then "11" \
when DECODE(nvl(temp_nalog.taxpayer_type, 1), 1, \
decode(trim(temp_nalog.tax_num), "не платник", "0", trim(temp_nalog.tax_num)), "0") = "0" \
then "02" \
else "" \
end || \
case when temp_nalog.status <> 1 \
then "У" \
else "" \
end document_type, \
max(case when is_correction = 0 \
then "" \
when trim(temp_nalog.correct_reason) in ("01","03") \
then trim(temp_nalog.correct_reason) \
else "02" \
end) correct_reason, \
sum(temp_nalog.summa - temp_nalog.summa_pension) summa_all, \
sum(temp_nalog.summa_pension) summa_pension, \
sum(temp_nalog.summa_avans) summa_avans_all, \
RoundTax(sum((temp_nalog.summa - temp_nalog.summa_pension) * temp_nalog.nalog_percent / (100 + temp_nalog.nalog_percent)), 2) summa_nds, \
sum(case when temp_nalog.nalog_percent = 0 \
then temp_nalog.summa - temp_nalog.summa_pension \
else 0 \
end) summa_notnds, \
max((select max(nds_percent.percent) keep (dense_rank last order by nds_percent.setup_date) \
from nds_percent \
where nds_percent.setup_date <= temp_nalog.obor_date)) nalog_percent \
FROM (select i.obor_date, \
temp_nalog.oborinfo_id, \
temp_nalog.cez_id, \
temp_nalog.provider_id, \
temp_nalog.provider_taxdoc, \
temp_nalog.provider_taxnum, \
temp_nalog.provider_name, \
temp_nalog.personal_count, \
temp_nalog.abonstatus_id, \
temp_nalog.abon_name, \
temp_nalog.tax_doc, \
temp_nalog.tax_num, \
temp_nalog.nalog_percent, \
nvl(temp_nalog.pension_percent,0) pension_percent, \
temp_nalog.nalog_num, \
DECODE(temp_nalog.status, 3, SUBSTR(temp_nalog.nalog_series, 2), temp_nalog.nalog_series) nalog_series, \
temp_nalog.nalog_date, \
temp_nalog.nalog_num_old, \
temp_nalog.nalog_series_old, \
temp_nalog.nalog_date_old, \
min(decode(temp_nalog.pension_percent, 100, 99999999, temp_nalog.service_id)) service_id, \
temp_nalog.obor_date_calc, \
temp_nalog.ndstype_id, \
temp_nalog.formtype_id, \
temp_nalog.taxpayer_type, \
temp_nalog.is_correction, \
temp_nalog.correct_reason, \
temp_nalog.codification_code, \
temp_nalog.status, \
sum(temp_nalog.volume) volume, \
sum(temp_nalog.summa) summa, \
sum(temp_nalog.summa_avans) summa_avans, \
case when nvl(temp_nalog.pension_percent,0) = 0 \
then 0 \
when temp_nalog.pension_percent = 100 \
then sum(temp_nalog.summa) \
else RoundTax(sum(temp_nalog.summa) * temp_nalog.pension_percent \
/ (100 + temp_nalog.nalog_percent + temp_nalog.pension_percent), 2) \
end summa_pension \
FROM &&&.obor_nalog temp_nalog, &&&.obor_info i \
WHERE temp_nalog.oborinfo_id = i.oborinfo_id ";

← →
Ega23 © (2012-12-24 14:14) [26]

> Вот пример далеко не самого большого запроса, оформленного
> "по правилам".

Вот такое я бы точно в виде view оформлял.

← →
Ega23 © (2012-12-24 14:17) [27]

> Обсуждение показывает, что нет какого-то одного единственно
> правильного решения. Более того, одни и те же люди используют
> то один подход, то другой.

Дело не в этом. Просто в одной компании, где я работал, было принято префикс и для вторичного, и для первичного писать.
Где сейчас работаю - префикс для первичного писать не принято.
Лично мне "переключиться" - дело пятнадцати минут.
практика показывает, что не надо применять названия Table1, Column2, Domain3 и StoredProc4, так точно запутаешься.

← →
Аббат Пиккола (2012-12-24 14:18) [28]

Боюсь, что если его "не по правилам" оформить, то от этого он лучше не станет.

← →
vuk © (2012-12-24 14:53) [29]

У нас делается так - для каждой таблицы выбирается префикс и все поля имеют вид Префикс_Имя. В связанных таблицах поля имеют те же имена, что и в основной.
Типа того:

GoodsTypes
-----------
gt_id int
gt_Name varchar
gt_DisplayOrder
...

Goods
-----------
g_id int
gt_id int
g_Name varchar
...

← →
Jeer © (2012-12-24 15:00) [30]

Ну да, это не суть как именовать префикс - табличным именем или алиасом.
Во втором случае можно сделать короче, но нужна таблица перевода :)

← →
Аббат Пиккола (2012-12-24 15:01) [31]

Жаль, что нет ресурса, на котором все бы выложили свои стили.
А разработчик нового проекта мог бы ознакомиться с ними и выбрать что-то наиболее подходящее.
Например, подход vuk © (24.12.12 14:53) [29] обладает строгостью и одновременно достаточно лаконичен.

← →
Аббат Пиккола (2012-12-24 15:03) [32]

Инетересно. Ведь эти же алиасы затем можно использовать и при написании SQL-запросов как алиасы для самих таблиц.

← →
vuk © (2012-12-24 15:07) [33]

to Jeer © (24.12.12 15:00) [30]:

> Во втором случае можно сделать короче, но нужна таблица
> перевода :)

Для частоиспользуемых таблица перевода уже на подкорке. Для редкоиспользуемых достаточно посмотерть наименование полей в таблице. :)

Да, кстати, эти же префиксы, как правило, используются для псевдонимов в join-ах.

Единственный минус - префиксы иногда выходят зубодробительные. :)))

← →
Ega23 © (2012-12-24 15:25) [34]

> Жаль, что нет ресурса, на котором все бы выложили свои стили.
>
> А разработчик нового проекта мог бы ознакомиться с ними
> и выбрать что-то наиболее подходящее.
> Например, подход vuk © (24.12.12 14:53) [29] обладает
> строгостью и одновременно достаточно лаконичен.

Я, к сожалению, не могу найти документа сейчас. Но он был, где-то на 4 странички, "Соглашения о наименованиях".
Там всё чётко было расписано, как формируется название столбца, какие символы не могут присутствовать, какие типы данных для чего используются и т.д.
В целом - как vuk привёл, очень похоже.

← →
Toha_Nik (2012-12-24 15:33) [35]

Ну да, там где автоматом, как для часто используемых - порядок какой-то помогает, а где редко - все равно по связям смотришь..., а посмотрел, уже и не особо важно как названо(в памяти то не держишь).

← →
Компромисс1 (2012-12-24 15:51) [36]

MsGuns © (24.12.12 13:57) [25]

Странно, что не введен алиас для temp_nalog, хотя введен алиас для obor_info

← →
vuk © (2012-12-24 15:54) [37]

to Toha_Nik (24.12.12 15:33) [35]:

> а посмотрел, уже и не особо важно как названо(в памяти то
> не держишь).

Как названо, все равно важно. Использование уникальных префиксов еще позволяет обходиться без переименования полей в сложных запросах, в рамках БД просто не будет полей с одинаковым названием, но имеющих разный смысл.

← →
Ega23 © (2012-12-24 16:00) [38]

Вот, коллега прислал, тот самый документ.
Публикую выдержки, полностью - не могу, спасибо за понимание

1.2 Общие положения 1.2.1 Имена в БД должны максимально описывать соответствующие сущности. 1.2.2 Имена должны максимально соответствовать грамматике английского языка. 1.2.3 Имена не должны быть слишком длинными, но применяемые в них сокращения должны быть понятны и благозвучны. 1.2.4 В качестве имен не допускается применение слов, которые могут оказаться резервированными в используемых программных средах (например, слов ORDER, SELECT, DENY, etc) 1.2.5 Рекомендуемые регистры наименований – первые буквы заглавные, остальные – прописные, либо начальные буквы составляющих слов заглавные, остальные – прописные (CamelCaps). Использование подчеркиваний и прочих знаков не допускается. 1.3 Таблицы 1.3.1 Рекомендованная длина имен таблиц – не более 12 символов 1.3.2 Рабочие таблицы – списки именуются именем или его сокращением во множественном числе. Возможно составное имя. Например, Persons, Classes, ClassGroups, ClsGroups, ClsStates, Clstypes 1.4.2 Суффиксы. Универсальные имена в случае необходимости могут быть дополнены суффиксами, а также нумераторами (0,1,..). Использование в одном имени и суффиксов, и нумераторов не рекомендуется. <Имя>= <Универсальное имя><Суффикс>|<нумератор> Рекомендованные суффиксы: In – начальный, исходный (например, для дат) Out – конечный, выходной (например, для дат) Add – дополнительная или альтернативная информация Min – минимальное значение, тип данных int, numeric Max – максимальное значение, тип данных int, numeric Примеры: DateIn, DateOut, ValMin, ValMax, NrAdd, Nr1, Nr2. Примечание. При использование суффиксов однородные семантически поля будут стоять рядом в алфавитно-упорядоченном списке. 1.5 Хранимые процедуры 1.5.1 Имена хранимых процедур Имя хранимой процедуры составляется из префикса S_, описателя (наименования или аббревиатуры) обрабатываемой сущности, уточненного описателя сущности, и конкретного описателя действия, или общего описателя действия – слова «рroc»: <имя процедуры>=S_<описание сущности>[<уточненное описание>][<описание действия>|proc] Например, S_PersEdit, S_PersSearch, S_CarsProps, S_CarsProc, S_DOTCheck, S_DOTSync Рекомендованная длина имен процедур – не более 12 символов 1.5.2 Файлы хранимых процедур Файлы хранимых процедур должны называться по имени процедур. Примечание. Не рекомендуется включать несколько процедур в один файл. Хотя был опыт хранения в одном файле s_misc 15 сервисных процедур и функций общего назначения, практически, не менявшихся длительное время. При прогоне утилитой командной строки этот файл исполнялся в рамках одного соединения, что экономило время 14 коннектов.

Ну и т.д.

← →
Kerk © (2012-12-24 16:01) [39]

Меня иногда пугает глобальность и важность вопросов, поднимаемых и - главное - на полном серьезе обсуждаемых на этом форуме :)

← →
Игорь Шевченко © (2012-12-24 16:20) [40]

Joe Celko давно все рассказал, как и что называть

http://books.google.ru/books/about/Joe_Celko_s_SQL_Programming_Style.html?id=90c41yKz3IUC&redir_esc=y

← →
MsGuns © (2012-12-24 16:21) [41]

>Компромисс1 (24.12.12 15:51) [36]
>Странно, что не введен алиас для temp_nalog, хотя введен алиас для obor_info

Все просто: кто-то когда-то написал запрос, потом кто-то другой его точил, при этом прикрутил алиас туда, куда ему показалось "понятней", потом возможно, был третий и т.д. Все они, вероятно, работали по "правилам". А результат - "на лице".

Похожая система присутствует почти во всех оракульных логиках, с которыми приходилось иметь дело, независимо от размеров БД, предметной области, квалификации программистов и т.д. Такое ощущение, что все проектировалось одним мегасуперораклистом, а потом допиливалось скубентками-третьекурсницами по скорому :)

← →
Jeer © (2012-12-24 16:24) [42]

> Меня иногда пугает глобальность и важность вопросов, поднимаемых
> и - главное - на полном серьезе обсуждаемых на этом форуме
> :)

Готовимся разрабатывать авианосцы и софт для них - там нет мелочей:)

← →
Jeer © (2012-12-24 16:25) [43]

> Примечание. При использование суффиксов однородные семантически
> поля будут стоять рядом в алфавитно-упорядоченном списке.
>

Да это при любых поименованиях важно.

← →
MsGuns © (2012-12-24 16:27) [44]

>Игорь Шевченко © (24.12.12 16:20) [40]

Хорошая книжка. Наверное, этот Селко из Таити. Там приняты имена типа Тоткогородилаженарыбакапоймавшегоназаходесолнцарыбубольшуючемсамыйбольшойаллигат орвгодкогдабылбольшойнедородкреветки

← →
знайка (2012-12-24 16:31) [45]

SuperPuperDatabaseSuperPuperTableSuperPuperField сразу становится все яснее ясного. :)
Зачем увеличивать число сущностей без крайней необходимости?

← →
Jeer © (2012-12-24 16:31) [46]

Для DBTree вариантов тоже давно выработался стандартный для меня принцип наименования суффиксов:

ID - пк (причем - autoinc навсегда исключен и выброшен на помойку)
REF - внутренняя ссылка на пк
[LINK] - внешняя ссылка
[LEV] - уровень узла в дереве
ORD - порядок сортировки
TXT - наименование
[MEM] - мемо

[] - необязательные поля

← →
Jeer © (2012-12-24 16:32) [47]

> Там приняты имена

ага, только без перевода на русский :)

← →
MsGuns © (2012-12-24 16:32) [48]

Вообще поражает талант америкосов писать толстенные книжки на высосанные из пальца темки. И совершенно шокирует способность тех же америкосов покупать эти книжки огромными тиражами и даже их читать :)

← →
MsGuns © (2012-12-24 16:35) [49]

>причем - autoinc навсегда исключен и выброшен на помойку

А ренегатов, таки допускающих такую крамолу - сразу на бубуку !

← →
Jeer © (2012-12-24 17:10) [50]

> сразу на бубуку !

Тебе виднее, раз знаешь куда и как:)

← →
Ega23 © (2012-12-24 17:13) [51]

> Тебе виднее, раз знаешь куда и как:)

Инструмент "сиквенса" для определённой "области видимости" должен быть.
Использовать его или нет - дело личных половых предпочтений.

← →
Jeer © (2012-12-24 17:50) [52]

> Инструмент "сиквенса" для определённой "области видимости"
> должен быть.

Инструменты у всех под рукой, кому надо и кто может - тот знает чем затачивать и для чего.
Кто не знает и не может - должен пройти этот путь.

← →
знайка (2012-12-24 17:54) [53]

А чем autoinc так не угодил?

← →
Kerk © (2012-12-24 18:16) [54]

> Jeer © (24.12.12 16:24) [42]
>
> > Меня иногда пугает глобальность и важность вопросов, поднимаемых
> > и - главное - на полном серьезе обсуждаемых на этом форуме
> > :)
>
> Готовимся разрабатывать авианосцы и софт для них - там нет
> мелочей:)

Ну тогда да :)

← →
Jeer © (2012-12-24 18:16) [55]

Холивары начинать не будем:)

← →
Toha_Nik (2012-12-24 19:16) [56]

> vuk © (24.12.12 15:54) [37]

Наверно да... и теоритетически правильно
Исключительно для меня проще - переименовать часто используемое ссылочное поле(но на памяти), написать комментарий при необходимости и при просмотре запроса прочитать этот комментарий, а не вспоминать префикс.

Это просто рассуждение, возможно не разрабатывал настолько сложные бызы...

← →
Smile (2012-12-24 20:15) [57]

Замечательный отлмчительный признак нашегш форума.
Автора топика уже нет как более полутора суток, а дискуссия продожается
:)

← →
Аббат Пиккола (2012-12-24 20:26) [58]

Kerk © (24.12.12 16:01) [39]
Меня иногда пугает глобальность и важность вопросов

Может быть вопрос о том, как назвать ребенка и не столь важен по сравнению с вопросом, когда или чем его кормить.
Но ведь именно этот вопрос всегда решается через обсуждение.
:)

← →
Дмитрий С © (2012-12-25 01:36) [59]

> vuk © (24.12.12 14:53) [29]
> У нас делается так - для каждой таблицы выбирается префикс
> и все поля имеют вид Префикс_Имя. В связанных таблицах поля
> имеют те же имена, что и в основной.

В таком случае остается открытый вопрос по поводу двойных ссылок: когда одна таблица имеет две ссылки на другую.

> Ega23 © (24.12.12 16:00) [38]

От одного человека из вашей организации я слышал, что "перфиксы - зло".

← →
Ega23 © (2012-12-25 08:24) [60]

> От одного человека из вашей организации я слышал, что "перфиксы - зло".

Ты имел какое-то отношение к НПК "Дедал"?

← →
Jeer © (2012-12-25 09:13) [61]

> открытый вопрос

для некоторых давно закрыт -надо правильно проектировать базу.

← →
Дмитрий С © (2012-12-25 10:51) [62]

> Ты имел какое-то отношение к НПК "Дедал"?
>

Нет, я, видимо, про другую организацию.

← →
Ega23 © (2012-12-25 11:05) [63]

> Нет, я, видимо, про другую организацию.

В другой организации префиксы не жалуют, да. Стиль другой.
Впрочем, меня не парят оба способа. Хотя если с нуля начинать и иметь карт-бланш, то префиксы всё-таки наверное ставил бы.

← →
vuk © (2012-12-25 11:10) [64]

to Дмитрий С © (25.12.12 01:36) [59]:

> В таком случае остается открытый вопрос по поводу двойных
> ссылок: когда одна таблица имеет две ссылки на другую.

Если ссылок необходимо несколько, то дополнительно в названии ссылающегося поля указывается контекст:

Clients
------------
cl_id int
cl_Name varchar
...

SomeOtherTable
------------
...
cl_id_Supplier int
...
cl_id_Recipient int
...

← →
Игорь Шевченко © (2012-12-25 12:21) [65]

> Хотя если с нуля начинать и иметь карт-бланш, то префиксы
> всё-таки наверное ставил бы.

Путаницы с ними много

← →
vuk © (2012-12-25 12:25) [66]

to Игорь Шевченко © (25.12.12 12:21) [65]:

> Путаницы с ними много

Например?

← →
Eraser © (2012-12-25 12:26) [67]

Префиксы это зло, особенно если они повторяют название таблицы. Если так уж хочется подставить название таблицы, то это можно сделать и без префикса - table_name.field_name

← →
Kerk © (2012-12-25 12:41) [68]

Я бы еще подумал над вопросом авторских прав. Что вы будете делать в том случае, если компания Apple в своей БД уже использовала имя NEW_ID?

← →
Аббат Пиккола (2012-12-25 12:56) [69]

2 Дмитрий С ©

Есть еще один путь для решения проблемы "двойных ссылок". Использовать не имена, а типы полей.

На примере InterBase. Создаем таблицу Contragent. С "лаконичными" именами полей id, name. Создаем domain TContragent на основе integer not null.

А в таблице SomeOtherTable две ссылки на таблицу Contragent создаем с общим типом TContragent, но разными именами:

SomeOtherTable
---------------------------
Id integer not null
OrderDate date not null
OrderNr varchar(20) not null
Customer TContragent
Vendor TContragent

Тогда мы получаем максимально лаконичное именование полей и нам даже не нужно использовать суффикы Id или иные признаки для ссылочных полей в их наименованиях, вместо этого мы оговорили в типах полей все, что нам нужно.

← →
знайка (2012-12-25 13:01) [70]

Еще для процедур префиксы, в целях группировки, а следовательно и навигации. Помогает. А для полей смысл в них мало понятен.

← →
Игорь Шевченко © (2012-12-25 13:04) [71]

vuk © (25.12.12 12:25) [66]

> Например?

CREATE OR REPLACE TRIGGER taiu_dic_currency_names AFTER INSERT OR UPDATE ON dic_currency_names FOR EACH ROW BEGIN IF :NEW.crn_culture = se_culture_tools.se_int_culture THEN UPDATE dic_currency_base SET cur_name_int = :NEW.crn_name WHERE cur_code = :NEW.crn_code; ELSIF :NEW.crn_culture = se_culture_tools.se_nat_culture THEN UPDATE dic_currency_base SET cur_name_nat = :NEW.crn_name WHERE cur_code = :NEW.crn_code; END IF; END; /

достаточно забыть/спутать одну букву :)

← →
Игорь Шевченко © (2012-12-25 13:05) [72]

Аббат Пиккола (25.12.12 12:56) [69]

Домены не везде есть

← →
vuk © (2012-12-25 13:18) [73]

to Игорь Шевченко © (25.12.12 13:04) [71]:

> достаточно забыть/спутать одну букву :)

Ну, некоторые вообще не приходя в сознание кодят. Но это же не повод. :) На самом деле да, проблема может возникнуть, конечно, но, как мне кажется, ты её несколько преувеличиваешь. Впрочем, я тут исключительно по себе сужу, у нас никто пока в основной базе с её около 1000 таблиц в префиксах не путается. А вот то, что по имени поля почти сразу видно где искать его источник и то, что поля называются везде и всегда одинаково и не переименовываются в запросах (за тем исключением, когда таблица присоединяется несколько раз), оно сильно облегчает жизнь.

← →
Anatoly Podgoretsky © (2012-12-25 13:19) [74]

> Нет, я, видимо, про другую организацию.

И ее закроют.

← →
Ega23 © (2012-12-25 13:20) [75]

Единственный плюс в префиксах: для join-запросов, когда несколько "ID" попадается, не надо as вписывать.
Больше не вижу, если честно.

← →
Медвежонок Пятачок © (2012-12-25 13:22) [76]

Банальнейший пример:
ловим исключение : бла бла бла нарушено ограничение такое то обнаружена порожденная запись <Имя поля>

далее desc <имя поля> - и видим полную картину маслом.
Если конечно префикс есть.
Если нет, то ничего не видим.

← →
Медвежонок Пятачок © (2012-12-25 13:22) [77]

пардон, не desc, а view конечно же

← →
vuk © (2012-12-25 13:27) [78]

to Ega23 © (25.12.12 13:20) [75]:

> Единственный плюс в префиксах: для join-запросов, когда
> несколько "ID" попадается, не надо as вписывать.

Если бы тока ID, то оно еще ладно, а то ведь сущности обрастают всякой "фигнёй" типа наименований, дополнительной информации или там, например, дат создания/модификации. :)

vuk © (25.12.12 13:18) [73]

> у нас никто пока в основной базе с её около 1000 таблиц
> в префиксах не путается

У нас поболе будет. Одно время практиковал создавать таблицы с именами полей с префиксом, а view для них, соответственно, с именами полей без префиксов. Везде есть свои плюсы и минусы.

← →
знайка (2012-12-25 13:35) [81]

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

В исключениях пишут какое поле и из какой таблицы, или где-то не так?

> Если бы тока ID, то оно еще ладно, а то ведь сущности обрастают
> всякой "фигнёй" типа наименований, дополнительной информации
> или там, например, дат создания/модификации. :)

Ну да, я в целом.
Банальный пример:

create table groups ( id int caption varchar ) create table entities ( id int, groupid int, caption varchar )
и банальный запрос с клиента

select g.caption, e.id, e.groupid, e.caption as entitycaption from groups g join entities e on (g.id=e.groupid)

А когда таких id, caption, changetime, imageindex, sortorder и ты.ды. дофига, тогда ой.

to Игорь Шевченко © (25.12.12 13:34) [79]:

> У нас поболе будет.

Ну так я и говорю - мож пока не доросли до путаницы. Гораздо большей проблемой уже давно является плохая впихуемость в голову всех тонкостей функционирования. От этого правильными именованиями уже не спасешься. :)

to Ega23 © (25.12.12 13:40) [82]:

> и банальный запрос с клиента
> select g.caption, e.id, e.groupid,
> e.caption as entitycaption from groups g join entities
> e on (g.id=e.groupid)

Угу, в том и пакость, что я сегодня могу написать "e.caption as entitycaption", а завтра "e.caption as фигзнаетчо". Потому, что лень искать, как в других местах переименовали. :)

vuk © (25.12.12 13:44) [83]

> Гораздо большей проблемой уже давно является плохая впихуемость
> в голову всех тонкостей функционирования. От этого правильными
> именованиями уже не спасешься. :)

Не сыпь мне соль на рану :)

> Угу, в том и пакость, что я сегодня могу написать "e.caption
> as entitycaption", а завтра "e.caption as фигзнаетчо". Потому,
> что лень искать, как в других местах переименовали. :)

Вьюхи спасают. но это тоже дело такое, неоднозначное.

> В данном случае совсем не спасают.

В одном месте править. Хотя это уже совсем другой холивар :)

← →
Аббат Пиккола (2012-12-25 16:17) [89]

Подозреваю, что при росте проекта всякая, поначалу казавшаяся блестящей и оптимальной, архитектура рано или поздно упирается в пределы своих возможностей. И приходится выбирать новую архитектуру.

> что при росте проекта всякая, поначалу казавшаяся блестящей
> и оптимальной,

но недальновидно спроектированная архитектура... и т.д.

> Игорь Шевченко © (25.12.12 16:41) [90]
> Ega23 © (25.12.12 15:32) [88]
>
> Ты предлагаешь на каждый запрос создавать view ? А зачем ?

В некоторых СУБД запросов фактически нет, есть только view :)

> Ты предлагаешь на каждый запрос создавать view ? А зачем?

Я ничего не предлагаю. Я просто о плюсах и минусах префиксов.
В принципе, было бы неплохо, чтобы имя поля в БД было уникальным.

> В принципе, было бы неплохо, чтобы имя поля в БД было уникальным.

Попробовав разное, к этому приходят не все, но многие.

to Ega23 © (25.12.12 17:10) [93]:

> Я ничего не предлагаю. Я просто о плюсах и минусах префиксов.
> В принципе, было бы неплохо, чтобы имя поля в БД было уникальным.
>

Я бы сказал не так. Поля, хранящие одинаковые по смыслу данные должны, по возможности, называться одинаково.

> Поля, хранящие одинаковые по смыслу данные должны

Ну.. тут вопрос скорее о ссылочных делах, но префикс, привязывающий поле к таблице, нисколько не отменяет семантическую идентичность его ( поля ) в рамках БД.

http://www.youtube.com/watch?v=_Hl4iDfARv8

неужели это еще не внесли в список экстремистких материалов?

> и да, имена полей в таблице не должны дублировать ее имя.
>
>

Единственный раз случайно нарушил это правило, но проблем не заполучил.

> Дмитрий С © (23.12.12 14:07)
>
> Предположим таблица новостей `new`.
> Как лучше назвать поле PK:
> id или new_id ?
>

По мне лучше так:
Таблицу назвать news, а поле id_new. Ибо это не столь идентификатор таблицы, сколь идентификатор конкретной новости.

← →
знайка (2012-12-26 12:33) [103]

> Единственный раз случайно нарушил это правило, но проблем
> не заполучил.
Откуда им взяться, с неба упадут?

> [102] Германн © (26.12.12 02:46)
> id_new

Ещё не лучше, весь цимус пропадает от этого new.

Надо всё называть тем, что пришло в голову причём по-русски транслитерацией не заморачиваясь о системе транслитерации - как вот сейчас захотелось, так и пишем можно знакомые английские слова добавить. Если в имени грамматическая ошибка - не исправлять, ибо лень - так дальше с ней и писать везде. Так, что ещё могу посоветовать? В общем главное - чтобы работало, имена выдумывают лохи, нормальному программеру некогда такими глупостями заниматься - ему кодить надо.

← →
Пит (2012-12-26 13:04) [105]

Программисты такие программисты ))

Обсуждаемые проблемы в реальных проектах вообще проблемами не являются, по сути. Во всех проектах, которые я видел - всегда есть гораздо более хреновые вещи, которые мешают жить. В контексте чего PK называй хоть id, хоть news_id, хоть my_beautiful_key.

Конечно, это потому что я видел исключительно хреновые проекты.

> это потому что я видел исключительно хреновые проекты.

Мне повезло - вообще чужие не видел и дасть Тот, не увижу.
А свои я хреновыми не назову:)

> А свои я хреновыми не назову:)

Это вообще большая загадка: откуда берутся хреновые программы?

От тех, кто смотрит чужие хреновые и копирует:)

> знайка (26.12.12 12:33) [103]
>
>
> > Единственный раз случайно нарушил это правило, но проблем
> > не заполучил.
> Откуда им взяться, с неба упадут?

А фиг их знает! Но иметь в программе два идентификатора с одним именем - это напряжно.

> [109] Германн © (28.12.12 02:12)
> Но иметь в программе два идентификатора с одним именем - это напряжно.

А имена полей/функций одинаковые в разных классах?

Название поля первичного ключа. Найти похожие ветки