О именовании таблиц в БД

[Bleed-the-sky]

Натыкался на мнение, что таблицы в БД стоит называть не во множ. а в ед.числе. НЕ Products, а Product . С моделями то понятно, там Product это один AR объект, который представляет одну строку таблицы, т.е. (напр) - 1 продукт. Не пойму почему саму таблицу БД то стоит называть Products? И еще это только для YII такая рекомендация, или вообще любого веб-проекта?

[solo]

Чтобы не парится с правилами и исключениями пишите все в единственном числе.

[yan]

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

[GeX]

но одно из исключений - news

[lynicidn]

новость

news, novelty, piece of news, item, breeze

[SiZE]

Натыкался на мнение, что таблицы в БД стоит называть не во множ. а в ед.числе.

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

[mickgeek]

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

Кстати, Microsoft в своих проектах именует таблицы в единственном числе.

[SiZE]

Кстати, Microsoft в своих проектах именует таблицы в единственном числе.

Вот это вообще не показатель =)

Именование таблиц в единственном числе удобно, практично и уменьшает риск запутаться, если система сложная

Чем единственное число удобней чем множественное? В чем ты там путаешься?

Лучше следить чтобы таких криворуких наименователей не было

Создала такую модельку:

Код: Выделить всё

class DinamikForm extends CFormModel

[mickgeek]

Именование таблиц в единственном числе удобно, практично и уменьшает риск запутаться, если система сложная

Чем единственное число удобней чем множественное? В чем ты там путаешься? :lol:

Мне удобно их именовать, да и удобно использовать такие названия, например, при создании внешних ключей. А путаница... ради эксперимента советую на досуге переименовать в другую форму те таблицы Microsoft ;)

[Bleed-the-sky]

Для меня пока кажется наоборот ед.число - путаницей (может просто "прока") . Например создаю геттер для релайшена, получить категории продукта, как назвать его? Получается getCategory ? Чтоб везде уж было тогда ед.число. В комментариях создаю геттер получить категорию (к которой относится комментарий), и он (хоть и в другой модели), но тоже getCategory. Там hasMany, тут hasOne, однако везде getCategory.

[anton44eg]

а причем тут релейшены?) называейте их как удобно

[Bleed-the-sky]

Ок. Ясненько

[GeX]

получить категории продукта, как назвать его? Получается getCategory ?

getCategoryList
getCategoryListArray, getCategoryListOfArrays (если предполагается что будет массив массивов)
getCategoryListObject, getCategoryListOfObjects (если предполагается что будет массив объектов)

второй вариант (мне нравится больше в плане краткости, хотя первый привычнее):
getCategoryList (если предполагается массив объектов, например тех же AR)
fetchCategoryList (если на возврате массив массивов)

То есть фишка именно в том что нет путаницы в окончаниях и единичных-множественных словоформах. Item - одна хрень, ItemList - список хреней, массив... Да, Item и Items вроде было бы хорошо, однако что делать со словами имеющими нестандартное множественное число? Man-Men, например - коверкать?

[slavcodev]

А есть еще ListList
Вижу тут смешались люди, кони, таблицы, релайшены и еще много чего все в кучу

Например создаю геттер для релайшена, получить категории продукта, как назвать его? Получается getCategory ?

По твоей логике, has_one свзяи ты тоже называешь getCategories()?

И вообще таблица это не коллекция сущностей, это набор строк, а уже в каждой строке сущность. Улавливаете мысль? Так что ничего общего между нахванием таблицы и названием класса сущности. Но для удобства лучше называть в единственном числе

1) Название берем сразу из класса get_class($this) в родительском классе, и забыли о названиях таблиц, тем более думать как перевести его в множественное число (да, да, у меня названия таблиц копия класса, даже регистр букв)
2) Таблицы состоящие из двух слов, часто не получается в множественном числе писать, например products_categories, ведь категории не продуктов, а категори продукта, мешать тоже не дело product_categories, я как программист не люблю исключения. Вот пытаюсь быть последовательным и писать в одной форме product_category, post_tag_assn

[Bleed-the-sky]

А есть еще ListList

Например создаю геттер для релайшена, получить категории продукта, как назвать его? Получается getCategory ?

По твоей логике, has_one свзяи ты тоже называешь getCategories()?

Почему? hasOne getCategory

[Bleed-the-sky]

getCategoryList

Думаю неплохо)

getCategoryListOfArrays (если предполагается что будет массив массивов)

Наверно перебор) А если getCategoryListOfArraysOfArraysOfArrays Хотя можно конечно условится обозначать только верхний уровень

[mickgeek]

getCategoryListOfArrays (если предполагается что будет массив массивов)

Наверно перебор) А если getCategoryListOfArraysOfArraysOfArrays Хотя можно конечно условится обозначать только верхний уровень

А можно не заниматься извращениями, а просто, как написал ранее anton44eg, называть функции отдельно от табличных имён, getCategories(). Один проект и Вы уже привыкли к таким наименованиям)

[mickgeek]

1) Название берем сразу из класса get_class($this) в родительском классе, и забыли о названиях таблиц, тем более думать как перевести его в множественное число (да, да, у меня названия таблиц копия класса, даже регистр букв)

А у столбцов какие имена, CamelCase или underscore?

[GeX]

getCategoryListOfArrays (если предполагается что будет массив массивов)

Наверно перебор) А если getCategoryListOfArraysOfArraysOfArrays Хотя можно конечно условится обозначать только верхний уровень

В мире где в IDE существует автокомплит длинные имена не так уж страшны Зато я вижу что мне возвращается - иногда это оправдано (хотя вот прямо сейчас в проекте у меня вообще вся работа с выводом данных из БД построена на DAO-подходе с гидрацией результата, в итоге на выходе всегда нечто отнаследованное от ArrayObject и описанное отдельно для автокомплита в IDE)