Исключительные или множественные имена таблицы базы данных? [дубликат]
Вы можете получить ключ, вернув его с данными:
data: any;
readData() {
this.db.list('listname').snapshotChanges().pipe(map(list => {
return list.map(items => {
return {key: items.payload.key, ...items.payload.val()}
})
})).subscribe(data => {
this.data = data;
});
}
13 ответов
ИМХО, имена таблиц должны быть множественными, как «Клиенты».
Имена классов должны быть единственными, как «Клиент», если они отображаются в строку в таблице «Клиенты».
Единственного числа, поэтому вы можете иметь:
- Customer
- CustomerAddress
- CustomerAddressAuditTrail
и т. Д.
Мне нравятся единичные имена, но, похоже, они в меньшинстве.
Мне нравится использовать единичные имена, такие как Agent, с именами PK, такими как AgentID.
Но это только я: o)
Моя личная философия заключается в том, что использование множественного имени таблицы базы данных является излишним, если только вы не планируете, чтобы таблица содержала одну строку.
Мне нравится использовать формы множественного числа, просто потому, что одна таблица содержит несколько сущностей, поэтому мне это кажется более естественным.
Linq to SQL преобразует имена таблиц множественного числа в единственное число при создании объектов данных. Я предполагаю, что Microsoft не внедрила бы эту функциональность, если бы считала множественные формы имен таблиц плохой практикой.
Ну, очевидно, что имена таблиц вашей базы данных абсолютно получили для именования «стандартным» способом, который я до сих пор буду произвольно определять.
Во-первых, все имена таблиц должен иметь префикс "t_". После этого имя единственного лица в StudlyCaps, например, «Клиент». Сразу после этого он должен содержать количество столбцов, созданных в первой версии схемы, для исторических целей с последующим подчеркиванием и точную нормальную форму данных; либо «1», «2», «3» или «B» для BCNF. Любые высшие нормальные формы должны быть обозначены буквой "P".
Некоторые примеры допустимых имен:
t_Customer_6_3
t_Order_5_B
t_OrderLine_4_2
Я думаю, моя точка зрения такова, что действительно не имеет значения ,
В моей нынешней компании мы используем Plural для имен таблиц. Аргументация такая:
Самое главное - быть последовательным в использовании. Раздражает необходимость вспоминать, какие таблицы являются множественными, а какие нет. То же самое с именами полей, выберите один стандарт и используйте его. Не заставляйте бедных разработчиков определять, использует ли эта таблица person_id или personid или peopleid или person $ id и т. Д. Удивительно, сколько времени вы можете тратить, если у вас нет стандартов, пытающихся просто запомнить, какая таблица используется что.
Есть много аргументов для каждого, но все сводится к тому, что вы чувствуете себя комфортно. Ни один из них не прав.
Что действительно важно, так это то, что вы последовательны. Выберите один стандарт и придерживайтесь его, какой из них будет иметь меньшее значение.
Нет того или иного правильного ответа на этот вопрос. Это зависит от разработчика базы данных и программного обеспечения.
Что касается меня, я обычно использую единичные имена, потому что когда я делаю диаграмму ER, у меня есть сущность Customer, а не Customers, поэтому я придерживаюсь того же принципа, чтобы не запутаться.
Конечно, некоторые фреймворки предпочитают тот или иной стиль, поэтому вам следует лучше следовать этим практикам, когда вы их заметите.
ИМХО это на самом деле не имеет значения, просто делайте все, что вам удобно с вами и людьми, которые используют базу данных.
Я думаю, что подсознательно перечисляю основные таблицы данных с s и " список выбора "или таблицы внешних ключей и единственное число.
Как и во многих других типах вопросов, лучший ответ часто бывает «последовательным». Вы можете утверждать, что таблица представляет отдельную сущность и, как таковая, заслуживает единственного имени или что она содержит несколько экземпляров сущности, поэтому она должна быть множественной. Мой совет - подбросить монетку и использовать ее для всей базы данных (или придерживаться соглашения, в котором уже есть большинство).