Платформа сущностей и таблицы с множественными именами. Это проблема?

Question

Я работаю над базой данных, и все таблицы имеют множественные имена.Какова лучшая практика при использовании Entity Framework 4.

Также я думаю, что на сервере Sql не рекомендуется именовать таблицу «Клиенты», но следует называть ее «Клиент»

.в двух словах они проблемы при использовании имен таблицы множественного числа?Если хотите, чтобы они изменились. Мне нужны хорошие объяснения.

Любые предложения

Большое спасибо

Answer 1

Структура сущностей и таблицы с множественными именами. Это проблема?

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

Answer 2

Ради здравомыслия просто используйте единственную форму для всего, чтобы вы знали, что ваш клиент хранится в таблице клиентов.Отделите аспекты человеческого языка от программирования.Идея плюрализации глупа, когда речь заходит о программировании, например, скажем, вам нужно работать с Person, Fungus, Goose и всем, что еще имеет неясное правило плюрализации.Все знают, что программисты не умеют писать, а также почему правила естественного языка посягают на программирование?тогда вместо того, чтобы иметь такие вещи, как:

Список людей;Список грибов;Гусь [] гуси;

мы получаем список listOfPerson;Список listOfFungus;Goose [] arrayOfGoose;

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

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

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

Answer 3

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

Answer 4

Я бы посоветовал вам бороться с текущим фреймворком только в версии 1.0, если вы правильно используете формы множественного числа. Существуют усилия, направленные на расширение возможностей множественных и единичных форм, так что представления создаются в зависимости от того, является ли сущность единственной или множественной. Очевидно, что форма множественного числа даст вам список или набор чего-то, тогда как единичная сущность сама по себе является просто этой сущностью. Этот элементарный факт может привести к выводу, что типография может меняться в зависимости от того, какую форму вы выбираете в единственном или множественном числе.

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