Независимо от того, какой вы разработчик, время от времени мы сталкиваемся с API, который возвращает данные таким образом, что нам не нужно тратить много времени на их понимание. Но получение такого чистого и последовательного результата требует времени, усилий и опыта. Поговорим говорить коротко и по существу.   Таблица: это набор данных Первичный ключ: Это уникальный идентификатор таблицы Атрибут: означает свойство ваших данных. Например, name.user Тип данных: Типы данных представляют различные типы ваших данных. Например-string, int, timestamp и т. Д.  Если ваше имя атрибута содержит более 1 слова, отделите его snake_case. Не используйте camelCase или любой другой случай для согласованности.   Плохо Хорошо Улучшает читабельность Имена могут стать более независимыми от платформы  Никогда не используйте типы данных в качестве имени столбца. Это происходит в основном для параметров метки времени. Дайте ему осмысленное имя.   Использование типов данных может создать путаницу в конце приложения. Предоставление собственного имени дает больше контекста для использования параметра. Не используйте имена в верхнем регистре для своих атрибутов.   Позволяет избежать путаницы с ключевыми словами SQL в верхнем регистре Это может улучшить скорость набора текста  Не пытайтесь сократить имена столбцов ради пространства или любой другой логики. Старайтесь быть как можно более понятными.   Это правило способствует самодокументированному дизайну Исключение из правила-4-это когда у вас есть широко распространенная аббревиатура. В таких ситуациях выбирайте короткий.  Но если вы окажетесь в замешательстве, перейдите к полному имени. Это инвестиции, которые вы делаете на будущее.   Верьте или нет, я видел это достаточно. Никогда не используйте числа в имени столбца. Это признак очень плохой нормализации. Старайтесь избегать этого. Будьте очень осторожны при именовании таблиц, потому что длинные имена таблиц могут оказать плохое влияние в будущем. Короткие имена таблиц помогут вам при создании реляционных столбцов и связывающих таблиц. В каждой базе данных есть несколько зарезервированных слов. Определите их и избегайте. Postgres MySQL Oracle Всегда старайтесь использовать имена для таблиц в единственном числе. Это спорный вопрос, и у разных людей разные мнения. Но придерживайтесь одного. Это способствует согласованности с первичными ключами и таблицами подстановки Плюрализация иногда может быть сложной. Таким образом, наличие особых имен таблиц может упростить программирование. При создании таблицы соединений объедините имена двух таблиц в алфавитном порядке. Обычно это лучший способ, если вы не нарушаете правила нормализации данных. Если это один столбец, то он должен быть назван как id Это должно быть имя другой таблицы и упомянутого поля. Например, если вы ссылаетесь на person внутри вашего team_member таблица, то вы можете сделать это так. Нет смысла суффиксировать имена столбцов типами данных. Избегайте этого. Если вы создаете индекс, за именем таблицы следуют имена столбцов, на которые вы ссылаетесь   Суффикс ваших имен столбцов типа даты с _on или _date. Например, если у вас есть столбец для хранения обновленной даты, делайте так, Если у вашего имени столбца есть время, то суффикс их с _at или _time. Например, если вы хотите сохранить время заказа, то Если у вас есть имена столбцов логического типа, то префикс их is_ или has_. Если вы уже работаете над проектом, придерживайтесь соглашения, которому уже следует проект. Потому что Единственное, что хуже плохого соглашения, - это несколько соглашений Разрабатывая базу данных с нуля, имея в виду эти правила, вы заложите крепкий фундамент на будущее. Каковы ваши мысли? Есть ли правило, с которым вы не согласны? Я более чем рад продуктивному разговору в комментариях! Хорошего дня!