Дилемма именования таблиц: единственные и множественные имена [закрыто]

Да, но не всегда в изоляции

Позвольте мне уточнить:

Что такое единичный тест?

Из Эффективно работает с устаревшим кодом 1:

Термин единичный тест имеет долгую историю разработки программного обеспечения. Общим для большинства концепций модульных тестов является идея, что они являются испытаниями в изоляции отдельных компонентов программного обеспечения. Какие компоненты? Определение варьируется, но при модульном тестировании мы обычно занимаемся большинством атомных поведенческих единиц системы. В процедурном коде единицы часто являются функциями. В объектно-ориентированном коде единицы являются классами.

blockquote>

Обратите внимание, что с ООП, где вы найдете геттеры и сеттеры, единица - это класс, не обязательно индивидуальные методы.

Что такое хороший тест?

Все требования и тесты следуют форме Логика Хора :

{P} C {Q}

blockquote>

Где:

  • {P} является предварительным условием (, данным )
  • C является (, когда )
  • {Q} является постусловием (, затем )

Затем следует максим :

Тестирование, а не реализация

blockquote>

Это означает, что вы не должны проверять, как C достигает пост-состояния, вы должны проверить, что {Q} является результатом C.

Когда дело доходит до ООП, C является классом. Таким образом, вы не должны тестировать внутренние эффекты, а только внешние эффекты.

Почему бы не тестировать получатели и сеттеры в изоляции

У получателей и сеттеров может быть какая-то логика, но так долго эта логика не имеют внешнего эффекта - делая их компонентами bean-аксессуаров 2) тест должен будет заглянуть внутрь объекта и тем самым не только нарушить инкапсуляцию, но и протестировать реализацию.

Итак, вы должны 't тестирует получателей и сеттеров в изоляции. Это плохо:

Describe 'LineItem class'

    Describe 'setVAT()'

        it 'should store the VAT rate'

            lineItem = new LineItem()
            lineItem.setVAT( 0.5 )
            expect( lineItem.vat ).toBe( 0.5 )

Хотя если setVAT выдаст исключение, соответствующий тест будет подходящим, так как теперь есть внешний эффект.

Как вы должны тестировать геттеры и сеттеры?

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

Таким образом, тест для сеттеров и геттеров должен быть связан с внешним эффектом этих методов, а не с внутренними.

Например:

Describe 'LineItem class'

    Describe 'getGross()'

        it 'should return the net time the VAT'

            lineItem = new LineItem()
            lineItem.setNet( 100 )
            lineItem.setVAT( 0.5 )
            expect( lineItem.getGross() ).toBe( 150 )

Вы можете подумать для себя:

Подождите секунду, мы тестируем getGross() здесь not setVAT().

blockquote>

Но если setVAT(), что тест все равно потерпит неудачу.

1Feathers, M., 2004. Эффективно работает с устаревшим кодом. Prentice Hall Professional.

2Martin, R.C., 2009. Clean code: руководство по гибкому программному мастерству. Образование Пирсона.

1341
задан 7 revs, 2 users 63% 5 November 2017 в 04:11
поделиться

26 ответов

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

227
ответ дан Tom H 5 November 2017 в 04:11
поделиться

Если Вы пойдете то будет проблема, но если Вы останетесь, то это будет двойным.

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

4
ответ дан Patrick Harrington 5 November 2017 в 04:11
поделиться

Нет никакого "соглашения", которое требует, чтобы имена таблиц были исключительны.

, Например, у нас была таблица под названием "ОТКЛОНЕНИЯ" на дб, используемом процессом оценки, содержа записи, отклоненные от одного выполнения программы, и я не вижу оснований в не использовании множественного числа для той таблицы (называющий его, "ОТКЛОНЕНИЕ" было бы просто забавно, или слишком оптимистично).

О другой проблеме (кавычки) это зависит от диалекта SQL. Oracle не требует кавычек вокруг имен таблиц.

3
ответ дан Gabriele D'Antona 5 November 2017 в 04:11
поделиться

При использовании определенных платформ как Платформа Зенда (PHP), только мудро использовать множественное число для классов таблицы и исключительный для классов строки.

Так говорят, что Вы создаете $users объекта таблицы = новые Пользователи () и объявили, что класс строки Пользователь, которого Вы будете в состоянии позвонить новому Пользователю () также.

Теперь, если бы Вы используете исключительный для имен таблиц, необходимо было бы сделать что-то как новый UserTable () со строкой, являющейся новым UserRow (). Это выглядит более неуклюжим мне, чем просто наличие объектные Пользователи () для таблицы и Пользователя () объекты для строк.

3
ответ дан 2 revs 5 November 2017 в 04:11
поделиться

Я решил ту же проблему путем именования таблицы "Employee" (на самом деле "Сотрудники"). Я пытаюсь остаться подальше от любого конфликта с возможно зарезервированными словами. Даже "Пользователи" неприятно близки для меня.

1
ответ дан dkretz 5 November 2017 в 04:11
поделиться

Как другие упомянули здесь, соглашения должны быть инструментом для добавления к простоте использования и удобочитаемости. Не как кандалы или клуб для мучения разработчиков.

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

Эта практика также позволяет мне резервировать множественные имена таблиц для тех, которые хранят many-many отношения между моими объектами.

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

мне нравится использовать префиксы ограниченным способом (tbl для имен таблиц, sp_ для имен proc, и т.д.), хотя многие полагают, что это добавляет помеху. Я также предпочитаю названия CamelBack к подчеркиваниям, потому что я всегда заканчиваю тем, что совершил нападки + вместо _ при введении имени. Многие другие не соглашаются.

Вот другая хорошая ссылка для инструкций по соглашению о присвоении имен: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

Помнит, что наиболее важный фактор в Вашем соглашении - то, что оно имеет смысл людям, взаимодействующим с рассматриваемой базой данных. Нет никакого "Одного Кольца для Управления Их Всех" когда дело доходит до соглашений о присвоении имен.

8
ответ дан Chris 5 November 2017 в 04:11
поделиться

Какое соглашение требует, чтобы таблицы имели исключительные имена? Я всегда думал, что это были множественные имена.

пользователь А добавляется к таблице Users.

Этот сайт соглашается:
http://vyaskn.tripod.com/object_naming.htm#Tables

Этот сайт не соглашается (но я не соглашаюсь с ним):
http://justinsomnia.org/writings/naming_conventions.html

<час>

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

124
ответ дан 2 revs 5 November 2017 в 04:11
поделиться

Я придерживаюсь с [1 110] исключительный для имен таблиц и любого объекта программирования.

причина? То, что существуют неправильные множественные числа на английском языке как мышь в ‡’ мыши и овцы в ‡’ овцы . Затем если мне нужно набор , я просто использую мыши или овцы и иду дальше.

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

Так, мое правило: все исключительно, каждый набор вещей исключителен с добавленный s. Помогает с ORMs также.

37
ответ дан 2 revs, 2 users 78% 5 November 2017 в 04:11
поделиться

Возможные альтернативы:

  • Переименовывают скобки Использования таблицы SystemUser
  • , Сохраняют множественные имена таблиц.

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

9
ответ дан 2 revs 5 November 2017 в 04:11
поделиться

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

Мы делаем это для обеспечения однородности и между архитектурой базы данных и между архитектурой приложения с базовым пониманием, что таблица Users является набором Пользователь значения так же как Пользователи , набор в артефакте кода является набором Пользователь объекты.

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

28
ответ дан 2 revs, 2 users 71% 5 November 2017 в 04:11
поделиться

Я всегда думал, что это было немым соглашением. Я использую множественные имена таблиц.

(я верю, рациональное позади той политики - то, что она облегчает для генераторов кода ORM производить объект & классы набора, так как легче произвести множественное имя из исключительного имени, чем наоборот)

7
ответ дан James Curran 5 November 2017 в 04:11
поделиться

Мы выполняем подобные стандарты, при сценариях мы требуем [] вокруг имен, и где соответствующие спецификаторы схемы - прежде всего, это страхует ставки против будущих захватов имени синтаксисом SQL.

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

Это сохранило наши души в прошлом - некоторые наши системы баз данных работали 10 + годы от SQL 6.0 до SQL 2005 - путь мимо их намеченной продолжительности жизни.

14
ответ дан stephbu 5 November 2017 в 04:11
поделиться

Система tables/views из самого сервера (SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, и т.д.) является почти всегда множественным числом. Я предполагаю ради непротиворечивости, я последовал бы их примеру.

12
ответ дан 2 revs, 2 users 67% 5 November 2017 в 04:11
поделиться

Инструкции действительно там как просто это. Это "не установлено в камне", вот почему у Вас есть опция способности проигнорировать их.

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

  • tblUser
  • tblThis
  • tblThat
  • tblTheOther

я не предполагаю, что это - способ пойти, я также вижу, что пробелы использовали МНОГО в именах таблиц, которые я ненавижу. Я даже столкнулся с именами полей с идиотичными символами как? как будто сказать, что это поле отвечает на вопрос.

5
ответ дан BenAlabaster 5 November 2017 в 04:11
поделиться

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

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

, Практическая непротиворечивость иногда является лучшим стандартом...:)

my2cents---

9
ответ дан Borzio 5 November 2017 в 04:11
поделиться

Если Вы используете инструменты Object Relational Mapping, или будет в будущем, которое я предлагаю Исключительный .

инструменты Some как LLBLGen могут автоматически исправить множественные имена как Пользователи Пользователю, не изменяя само имя таблицы. Почему это имеет значение? Поскольку, когда это отобразилось, Вы хотите, чтобы он был похож на Пользователя. Имя вместо Пользователей. Имя или хуже от некоторых моих старых таблиц баз данных, называющих tblUsers.strName, который просто сбивает с толку в коде.

Мое новое эмпирическое правило должно судить, как это посмотрит, как только это было преобразовано в объект.

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

253
ответ дан Brian Boatright 5 November 2017 в 04:11
поделиться

Мне не нравятся множественные имена таблиц, потому что некоторые существительные на английском языке не исчисляемы (вода, суп, наличные деньги) или изменения значения при создании его исчисляемым (курица по сравнению с курицей; суть по сравнению с птицей). Мне также не нравится использовать сокращения для имени таблицы или имени столбца, потому что выполнение так добавляет дополнительный наклон к уже крутой кривой обучения.

Как ни странно, я мог бы сделать User исключение и назвать его Users из-за ПОЛЬЗОВАТЕЛЬ (Transac-SQL) , потому что мне также не нравится использовать скобки вокруг таблиц, если я не имею к.

мне также нравится называть все столбцы ID как Id, не ChickenId или ChickensId (что множественные парни делают об этом?).

Все это вызвано тем, что я не испытываю надлежащее уважение к системам баз данных, я просто повторно применяю знание с одним пони приема из соглашений о присвоении имен OO как Java из привычки и лени. Мне жаль, что не было лучшей поддержки IDE сложного SQL.

15
ответ дан Eugene Yokota 5 November 2017 в 04:11
поделиться

Исключительный. Я звонил бы, массив, содержащий набор пользовательского представления строки, возражает 'пользователям', но таблица является 'пользовательской таблицей'. Размышление о таблице, как являющейся только набором строк, которые это содержит, является неправильным, IMO; таблица является метаданными, и набор строк иерархически присоединен к таблице, это не сама таблица.

я использую ORMs все время, конечно, и помогает, что код ORM, записанный со множественными именами таблиц, выглядит глупым.

16
ответ дан chaos 5 November 2017 в 04:11
поделиться
  • 1
    наконец! это сделало это для меня. мне кажется, что должен был быть более простой метод, но судя, что потребовалось почти год для получения ответа, который работал на меня, я думаю, что это - он. огромное спасибо! – clayton33 6 November 2011 в 08:10

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

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

60
ответ дан 2 revs 5 November 2017 в 04:11
поделиться

Я - поклонник исключительных имен таблиц, поскольку они делают мои схемы ER с помощью синтаксиса СЛУЧАЯ, легче читать, но путем чтения этих ответов я получаю чувство, что он никогда не завоевывал популярность очень хорошо? Я лично люблю его. Существует хороший обзор с примерами того, насколько читаемый Ваши модели могут быть при использовании исключительных имен таблиц добавьте глаголы действия к отношениям и сформируйте хорошие предложения для каждого отношения. Это - все немного излишества для 20 баз данных таблицы, но если у Вас есть DB с сотнями таблиц и сложным дизайном, как Ваши разработчики будут когда-либо понимать его без хорошей читаемой схемы?

http://www.aisintl.com/case/method.html

Что касается добавления префикса таблиц и представлений я абсолютно ненавижу ту практику. Не дайте человеку информацию вообще прежде, чем дать им возможно плохую информацию. Любой просматривающий дб для объектов может довольно легко сказать таблицу от представления, но если у меня есть таблица, названная tblUsers, который по некоторым причинам я решаю реструктурировать в будущем в две таблицы, с целью объединяя их для удержаний от повреждения старого кода, у меня теперь есть представление, названное tblUsers. В этой точке меня оставляют с двумя непривлекательными опциями, оставляю представление названным с tbl префиксом, который может смутить некоторых разработчиков, или вынуждать другой слой, или средний уровень или приложение быть переписанным, чтобы сослаться на мою новую структуру или назвать viewUsers. Это инвертирует значительную часть значения представлений, по моему скромному мнению.

12
ответ дан Shane Delmore 5 November 2017 в 04:11
поделиться

Я просто дам свое мнение, почему я использую исключительный имена.

, Например, я должен получить все поля от пользователя:

-- Select every fields from 'user' table
SELECT * FROM user

мне нужно имя пользователя, которому 21 год:

-- Select every fields from 'user' table which have 21 years old
SELECT * FROM user WHERE age = '21'

, Конечно, множественный путь может использоваться теми же средствами, но для моего мозга для чтения я действительно думаю, что это - правильный способ пойти.

5
ответ дан 2 revs, 2 users 83% 5 November 2017 в 04:11
поделиться
  • 1
    @Craig, base() неявно назовут, если Вы не сделаете так непосредственно. Базовый класс будет создан перед производным классом, неважно, которым называют конструктор порожденного класса. – Anthony Pegram 30 June 2010 в 02:55

Как насчет этого как простой пример:

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

по сравнению с.

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

SQL в последнем является более странным звучанием, чем первый.

Я голосую за исключительный.

77
ответ дан 19 December 2019 в 20:14
поделиться

ИМХО, имена таблиц должны быть во множественном числе , как Клиенты .

Имена классов должны быть единичными, как Клиент , если это отображается на строку в таблице Customers .

34
ответ дан 19 December 2019 в 20:14
поделиться

Таблицы: множественное число

В таблице пользователей указано несколько пользователей.

Модели: единственное число

Единственного пользователя можно выбрать из таблицы пользователей.

Контроллеры: множественное число

http: //myapp.com/users будет перечислять нескольких пользователей.

В любом случае это мой вариант.

13
ответ дан 19 December 2019 в 20:14
поделиться

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

Я думаю, что сейчас склоняюсь в пользу единственного числа из-за неправильности множественного числа в английском языке. На немецком языке ситуация еще хуже из-за отсутствия согласованных форм множественного числа - иногда вы не можете определить, является ли слово множественным числом или нет, без уточняющего артикля перед ним (der / die / das). И в китайских языках все равно нет форм множественного числа.

8
ответ дан 19 December 2019 в 20:14
поделиться

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

Что мне не нравится во множественном числе имена таблиц в том, что объединенные имена могут быть довольно странными. Если, например, у вас есть таблица с именем Users , и вы хотите сохранить свойства для пользователя, это приведет к таблице с именем UsersProperties ...

4
ответ дан 19 December 2019 в 20:14
поделиться
Другие вопросы по тегам:

Похожие вопросы: