[sql][советы][именования][соглашения] Хороший тон. Как обзывать many-to-many таблицы?

Нагугливаются варианты:

— events_types (потенциально не очень хорошо, что похоже на event_types)
— event_x_type (x = «cross»)

Фантазия народа безгранична :)
— type_per_event
— event_has_type

- event_xref_type

Держи до кучи, для раздумий :)
event_types_link

На Авиабазе подкинули вариант «lnk_evt_evttype» :)

events2types

банально, events_event_types

events_event_types

Я в таких случаях просто объединяю два названия:

events_and_event_types

Из всех представленных вариантов более-менее выглядит разве что event_types_map :}

e2t

h2o

cocl2

b2b

C6H2CH3(NO2)3

по-хорошему имхо, таблица со связями должна быть как раз event_types, а список типов - чтото вроде refeventtypes или event_type_list.

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

P.S. Странный пример. Таблицы типов обычно являются словарём. Зачем тут вводить связку many-to-many, если в events можно id от event_types хранить?

т.е. events.types::int[] ?

А если events могут к нескольким типам относиться?

Зачем тут вводить связку many-to-many, если в events можно id от event_types хранить?

Потому что одно событие может быть нескольких типов.

madcore

А если events могут к нескольким типам относиться?

Если так, то да.

банально, events_event_types

Больше всего голосов (аж два :D) собрал этот вариант. Хотя я бы, тогда, обозвал как events__event_types. Так составные индексы обычно обзываю.

Но мне пока что-то больше нравится вариант events_x_types. Новую таблицу так обозвал, но на будущее вопрос всё равно в целом открыт.

events_event_types

Масло маслянное.

*_link, *_links я видел в реальных проектах и в веб-движках каких-то.

*_link, *_links я видел в реальных проектах и в веб-движках каких-то.

А так же _map, _cross, _index — это всё реальные примеры. И даже мной используемые ранее :)

Масло маслянное.

почему? название отражает, какие таблицы связывает промежуточная таблица. *_link же хз что.

сущности, вернее

Больше всего голосов (аж два :D) собрал этот вариант

в джанге так, если явно не указывать =)

events_event_types

+1

В рельсах так же.

есть у нас таблица events.

Таблицы надо называть в единственном числе

Таблицы надо называть в единственном числе

В ней содержится не одно событие, а множество.

В каждой записи?

events

В каждой записи?

В таблице содержится _много_ записей по одному событию в каждой. _Много_ событий. В таблице, не в записи. Таблица != запись.

Ты папку с документами назовёшь «документ» или, всё же, «документы»?

Ок, просто где-то слышал, что хороший тон это называть в единственном числе

events_event_types - я такую схему использую обычно. Но вариант events_x_event_types тоже понравился.

У нас так:

table1(pk, field1, field2, ...)
table2(pk, field3, field4,...)
table1_table2_xref(table1, table2) // many to many
table3(pk, table1, field5, ...) //table3 содержит FK на table1

Так ещё можно, не во всех СУБД правда:
events.events
events.types
events.events_types

имеется ввиду разделение по схемам что бы короткие имена типа types не пересекались, тогда логичным именем для M2M становится соединение коротких имён events_types.

Помню нам в университете активно продвигали теорию, что таблица должна именоваться не мн. ч., а ед. ч., т.е. «event» вместо «events» и «event_type» вместо «event_types».

По поводу именования связок я не видел каких-либо стандартов. Видел в интернете пример, где название таблицы связки отражает не технический ее характер, а логический: таблицы Orders и Products соединяются через таблицу OrderLines.

У меня в таких link фигурировало.

$имятаблицы1_$имятаблицы2_link, например

И после этого испражняться строительными блоками при попытке прикрутить ORM.

И после этого испражняться строительными блоками при попытке прикрутить ORM

А не пофиг, как базу обозвать с точки зрения ORM? Всё равно в одном месте же прописывается.

Только те ORM, которые я видел по дефолту используют Plural от имени объекта в качестве таблицы. Т.о. приходится на каждую модель еще дополнительно минимум 1 строку писать, указывая явно имя таблицы, чего с множественным числом в именах таблиц делать не пришлось бы.

Т.о. приходится на каждую модель еще дополнительно минимум 1 строку писать

Ну, поскольку таблиц новых в день не по 100 штук вводить приходится, то это не принципиальный момент :) Явно не тянет на «сраньё кирпичами». У меня на одну дефолтовую таблицу обычно приходится с десяток недефолтового legacy.

В любом случае, задавать имя таблицы явно — это чуть-чуть быстрее, чем рассчитывать его из имени класса ;)

Ну, ORM вообще не надо использовать тогда. Только plain SQL, только хардкор.

Ну, ORM вообще не надо использовать тогда

Всё, что не белое — чёрное? ;)

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

Только те ORM, которые я видел по дефолту используют Plural от имени объекта в качестве таблицы.

Это где так? В Хибернейте я подобного не припомню.

Вот прямо сейчас приходится вертеть хвосты Kohana::ORM. Насколько помню, в алхимии тоже так было, если использовать декларативный стиль.

значит, и ORM тоже дорого

В частностях, если без извращений, то на загрузке единичных объектов и массивов оверхед от ORM практически нулевой. В любом случае такой, на фоне которого экономия в фиксированном имени таблицы уже немного заметна :)