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

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

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

KRoN73 (28.11.2011 6:33:10)

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

KRoN73 (28.11.2011 6:34:42)

- event_xref_type

KRoN73 (28.11.2011 6:35:51)

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

madcore (28.11.2011 7:32:52)

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

KRoN73 (28.11.2011 7:41:14)

events2types

no-dashi (28.11.2011 9:41:12)

банально, events_event_types

anon1984 (28.11.2011 9:44:46)

events_event_types

kelyar (28.11.2011 9:45:53)

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

events_and_event_types

soomrack (28.11.2011 10:12:41)

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

Mystra_x64 (28.11.2011 11:04:24)

e2t

h2o

cocl2

b2b

C6H2CH3(NO2)3

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

arkhnchul (28.11.2011 12:18:58)

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

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

stolz (28.11.2011 12:57:11)

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

GateKeeper (28.11.2011 13:40:32)

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

madcore (28.11.2011 13:42:52)

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

KRoN73 (28.11.2011 13:44:30)

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

stolz (28.11.2011 13:45:09)

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

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

KRoN73 (28.11.2011 13:46:47)

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

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

madcore (28.11.2011 13:51:42)

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

KRoN73 (28.11.2011 14:28:43)

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

anon1984 (28.11.2011 14:29:53)

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

anon1984 (28.11.2011 14:32:09)

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

anon1984 (28.11.2011 14:33:28)

+1

Manhunt (28.11.2011 14:33:46)

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

placement_new (28.11.2011 14:36:47)

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

xorik (28.11.2011 14:51:43)

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

KRoN73 (28.11.2011 14:52:36)

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

xorik (28.11.2011 14:53:26)

events

nCdy (28.11.2011 14:55:24)

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

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

KRoN73 (28.11.2011 14:57:07)

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

xorik (28.11.2011 15:02:41)

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

Legioner (28.11.2011 15:08:00)

У нас так:

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

roller (28.11.2011 15:15:04)

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

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

Eshkin_kot (28.11.2011 16:01:34)

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

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

Ian (28.11.2011 17:06:55)

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

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

yoghurt (28.11.2011 17:07:49)

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

GateKeeper (28.11.2011 17:28:03)

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

KRoN73 (28.11.2011 17:39:14)

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

GateKeeper (28.11.2011 18:19:53)

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

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

KRoN73 (28.11.2011 18:23:42)

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

GateKeeper (28.11.2011 18:29:24)

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

KRoN73 (28.11.2011 18:34:50)

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

GateKeeper (28.11.2011 18:38:30)

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

Absurd (28.11.2011 18:38:38)

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

GateKeeper (28.11.2011 18:40:07)

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

KRoN73 (28.11.2011 18:56:37)