tkutru17 фев в 08:51

20 тейков по коммерческой разработке за 20+ лет работы разработчиком

Простой

2 мин

HabrУправление разработкой * Разработка под e-commerce * Карьера в IT-индустрии

Мнение

Комментарии 5

Kerman 17 фев в 09:08

Хотя бы чтоб перестать называть таблицу заказов как "order" в БД.

А что не так? Вроде устоявшийся термин, везде orders, во всех примерах. Есть purchase order как часть терминологии sap, например. Или то, что термин в единственном числе?

tkutru 17 фев в 09:14

Это просто пример, возможно в SAP есть такой стандарт и там это нормально.
Во многих других проектах вы будете страдать, занимаясь экранированием этого слова в запросах (а где забудете - получите баги), ибо оно ключевое зарезервированное во многих СУБД.

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

Kerman 17 фев в 09:40

Во многих других проектах вы будете страдать, занимаясь экранированием этого слова в запросах (а где забудете - получите баги), ибо оно ключевое зарезервированное во многих СУБД.

Во первых, не во "многих" а в ANSI SQL 92. Во-вторых таблицы принято называть сущностью во множественном числе, никаких коллизий при этом не происходит. При этом не понятна аргументация в сторону английского языка. Order - это совершенно корректный и общепринятый термин для обозначения заказа. Точка.

tkutru 17 фев в 09:54

Я уже сказал, что это один из примеров, их можно найти ещё и для всего. На базе ANSI SQL 92 есть много чего, MySQL, PostgreSQL, MariaDB (кто не любит проприетарщину мускуля), Transact SQL и прочее. Это так, навскидку. Это примерно 90% всего интернета, на минуточку. Если вы лично с этим не пересекались, то вы в меньшинстве и нет гарантий, что не пересечётесь никогда. В любом случае, основная идея, что очень ограниченное владение английским будет делать ваш код хуже, менее читабельным и поддерживаемым. Или вы с этим тоже не согласны?
Насчёт того, как где принятно называть таблицы, это не истина в последней инстанции, а стандарты конкретного стека и команды/проекта. Например - как по мне - т.к. в условном мускуле нет many-to-many из коробки, надо использовать таблицу сопряжения (junction table) и вот там вполне можно использовать plural. Типа authors_to_books и т.п. А вот когда обычная сущность, лучше singular (единственное число), почему? Потому что если дальше у вас там будет какой нибудь DAO+ORM типа ActiveRecord, то и название класса будет не Customer допустим а Customers, и это странно, ведь на ООП уровне вы часто будете работать с одной конкретной сущностью, обзывая её множественным числом. В любом случае, это вопрос принятых стандартов, и "истины в последней инстанции" я в этом вопросе не наблюдаю.

Kerman 17 фев в 10:42

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

Какого стека? Какого проекта? Какой ещё команды? Order - это термин из английского языка, обозначающий заказ. Упорядочивание тоже.

А вот когда обычная сущность, лучше singular (единственное число)

Не лучше

Потому что если дальше у вас там будет какой нибудь DAO+ORM типа ActiveRecord, то и название класса будет не Customer допустим а Customers

Не будет. В любой ORM можно сделать маппинг имени класса к таблице. Какие-то это автоматом делают, вроде EF, но всё равно можно руками поправить. Ну никто же не переносит напрямую имена таблиц из snake_case таблиц в языки с CamelCase стандартом. Таблица - "orders", класс "Order", репозиторий "Orders". Это стандарт индустрии, общепринятое соглашение.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий