Как создать чистую базу данных

18 лучших практик создания простых и последовательных имен

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

Терминология

Таблица: это набор данных

Первичный ключ: Это уникальный идентификатор таблицы

Атрибут: означает свойство ваших данных. Например, name.user

Тип данных: Типы данных представляют различные типы ваших данных. Например-string, int, timestamp и т. Д.

1. Слова должны быть разделены подчеркиванием

Если ваше имя атрибута содержит более 1 слова, отделите его snake_case. Не используйте camelCase или любой другой случай для согласованности.

Плохо

wordcount или WordCount

Хорошо

word_count

Причина

• Улучшает читабельность

• Имена могут стать более независимыми от платформы

2. Типы данных не должны быть именами

Никогда не используйте типы данных в качестве имени столбца. Это происходит в основном для параметров метки времени. Дайте ему осмысленное имя.

Плохо

timestamp or text

Хорошо

created_at or description

Причина

• Использование типов данных может создать путаницу на другом конце приложения.

• Предоставление собственного имени дает больше контекста для использования параметра.

3. Имена атрибутов должны быть строчными

Не используйте имена в верхнем регистре для своих атрибутов.

Плохо

Description

Хорошо

description

Причина

• Позволяет избежать путаницы с ключевыми словами SQL в верхнем регистре

• Это может улучшить скорость набора текста

4. Напишите полные слова

Не пытайтесь сократить имена столбцов ради пространства или любой другой логики. Старайтесь быть как можно более явными.

Плохо

mid_name

Хорошо

middle_name

Причина

Это правило способствует самодокументированному дизайну

5. Но используйте общие сокращения

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

Хорошо

i18n

Но если вы окажетесь в замешательстве, перейдите к полному имени. Это инвестиции, которые вы делаете на будущее.

6. Избегайте наличия чисел в имени столбца

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

Плохо

address1 , address2

Хорошо

primary_address, secondary_address

Причина

Это признак очень плохой нормализации на вашем конце. Поэтому старайтесь избегать этого.

7. Используйте короткие имена таблиц

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

Плохо

site_detail

Хорошо

site

Причина

Короткие имена таблиц помогут вам при создании реляционных столбцов и связывающих таблиц.

8. Ищите зарезервированные слова

В каждой базе данных есть несколько зарезервированных слов. Изучайте их и избегайте.

Плохо

user lock table etc

Список зарезервированных слов для некоторых популярных баз данных

• Postgres

• MySQL

• Oracle

9. Сингулярные имена для таблиц

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

Плохо

users and orders

Хорошо

user and order

Причина

• Это способствует согласованности с первичными ключами и таблицами подстановки

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

10. Таблицы ссылок должны иметь алфавитный порядок

При создании таблицы соединений объедините имена двух таблиц в алфавитном порядке.

Плохо

book_author

Хорошо

author_book

11. Имена столбцов в единственном числе

Обычно это лучшая практика, если вы не нарушаете правила нормализации данных.

Плохо

books

Хорошо

book

12. Имя первичного ключа

Если это один столбец, то он должен быть назван как id

CREATE TABLE order (
 id bigint PRIMARY KEY,
 order_date date NOT NULL
);

13. Имя внешнего ключа

Это должно быть имя другой таблицы и упомянутого поля. Например, если вы ссылаетесь на person внутри вашего team_member таблица, то вы можете сделать это так.

CREATE TABLE team_member (
 person_id bigint NOT NULL REFERENCES person(id),
);

14. Не указывайте в конце имен столбцов типы хранимых в них данных

Нет смысла суффиксировать имена столбцов типами данных. Избегайте этого.

Плохо

name_tx

Хорошо

name

15. Индексы должны иметь как имя таблицы, так и столбца

Если вы создаете индекс, за именем таблицы следуют имена столбцов, на которые вы ссылаетесь

CREATE TABLE person (
 id bigserial PRIMARY KEY,
 first_name text NOT NULL,
 last_name text NOT NULL,
);
CREATE INDEX person_ix_first_name_last_name ON person (first_name, last_name);

16. Имена столбцов типа даты

Суффикс ваших имен столбцов типа даты с _on или _date.

Например, если у вас есть столбец для хранения обновленной даты, сделайте это,

Хорошо

updated_on или updated_date

17. Имена столбцов типа даты и времени

Если у вашего имени столбца есть время, то суффикс их с _at или _time.

Например, если вы хотите сохранить время заказа, то

Плохо

ordered

Хорошо

ordered_at or order_time

18. Имена столбцов логического типа

Если у вас есть имена столбцов логического типа, то префикс их is_ или has_.

Хорошо

is_admin или has_membership

Заключение

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

Единственное, что хуже плохого соглашения, - это несколько соглашений

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

Каковы ваши мысли? Есть ли правило, с которым вы не согласны? Я более чем рад продуктивному разговору в разделе комментариев!

Хорошего дня!