Схема базы данных
Схемы используются в модели безопасности компонента Database Engine для упрощения взаимоотношений между пользователями и объектами, и, следовательно, схемы имеют очень большое влияние на взаимодействие пользователя с компонентом Database Engine. В этом разделе рассматривается роль схем в безопасности компонента Database Engine. В первом подразделе описывается взаимодействие между схемами и пользователями, а во втором обсуждаются все три инструкции языка Transact-SQL, применяемые для создания и модификации схем.
Разделение пользователей и схем
— это коллекция объектов базы данных, имеющая одного владельца и формирующая одно пространство имен. (Две таблицы в одной и той же схеме не могут иметь одно и то же имя.) Компонент Database Engine поддерживает именованные схемы с использованием понятия принципала (principal). Как уже упоминалось, принципалом может быть индивидуальный принципал и групповой принципал.
Индивидуальный принципал представляет одного пользователя, например, в виде регистрационного имени или учетной записи пользователя Windows. Групповым принципалом может быть группа пользователей, например, роль или группа Windows. Принципалы владеют схемами, но владение схемой может быть с легкостью передано другому принципалу без изменения имени схемы.
Отделение пользователей базы данных от схем дает значительные преимущества, такие как:
один принципал может быть владельцем нескольких схем;
несколько индивидуальных принципалов могут владеть одной схемой посредством членства в ролях или группах Windows;
удаление пользователя базы данных не требует переименования объектов, содержащихся в схеме этого пользователя.
Каждая база данных имеет схему по умолчанию, которая используется для определения имен объектов, ссылки на которые делаются без указания их полных уточненных имен. В схеме по умолчанию указывается первая схема, в которой сервер базы данных будет выполнять поиск для разрешения имен объектов. Для настройки и изменения схемы по умолчанию применяется параметр DEFAULT_SCHEMA инструкции CREATE USER или ALTER USER. Если схема по умолчанию DEFAULT_SCHEMA не определена, в качестве схемы по умолчанию пользователю базы данных назначается схема dbo.
Инструкция CREATE SCHEMA
В примере ниже показано создание схемы и ее использование для управления безопасностью базы данных. Прежде чем выполнять этот пример, необходимо создать пользователей базы данных Alex и Vasya, как будет описано в следующей статье (вы можете вернуться к этим примерам позже).
В этом примере создается схема poco, содержащая таблицу Product и представление view_Product. Пользователь базы данных Vasya является принципалом уровня базы данных, а также владельцем схемы. (Владелец схемы указывается посредством параметра AUTHORIZATION. Принципал может быть владельцем других схем и не может использовать текущую схему в качестве схемы по умолчанию.)
Две другие инструкции, применяемые для работы с разрешениями для объектов базы данных, GRANT и DENY, подробно рассматриваются позже. В этом примере инструкция GRANT предоставляет инструкции SELECT разрешения для всех создаваемых в схеме объектов, тогда как инструкция DENY запрещает инструкции UPDATE разрешения для всех объектов схемы.
С помощью инструкции CREATE SCHEMA можно создать схему, сформировать содержащиеся в этой схеме таблицы и представления, а также предоставить, запретить или удалить разрешения на защищаемый объект. Как упоминалось ранее, защищаемые объекты — это ресурсы, доступ к которым регулируется системой авторизации SQL Server. Существует три основные области защищаемых объектов: сервер, база данных и схема, которые содержат другие защищаемые объекты, такие как регистрационные имена, пользователи базы данных, таблицы и хранимые процедуры.
Инструкция CREATE SCHEMA является атомарной. Иными словами, если в процессе выполнения этой инструкции происходит ошибка, не выполняется ни одна из содержащихся в ней подынструкций.
Порядок указания создаваемых в инструкции CREATE SCHEMA объектов базы данных может быть произвольным, с одним исключением: представление, которое ссылается на другое представление, должно быть указано после представления, на которое оно ссылается.
Принципалом уровня базы данных может быть пользователь базы данных, роль или роль приложения. (Роли и роли приложения рассматриваются в одной из следующих статей.) Принципал, указанный в предложении AUTHORIZATION инструкции CREATE SCHEMA, является владельцем всех объектов, созданных в этой схеме. Владение содержащихся в схеме объектов можно передавать любому принципалу уровня базы данных посредством инструкции ALTER AUTHORIZATION.
Для исполнения инструкции CREATE SCHEMA пользователь должен обладать правами базы данных CREATE SCHEMA. Кроме этого, для создания объектов, указанных в инструкции CREATE SCHEMA, пользователь должен иметь соответствующие разрешения CREATE.
Инструкция ALTER SCHEMA
Инструкция ALTER SCHEMA перемещает объекты между разными схемами одной и той же базы данных. Инструкция ALTER SCHEMA имеет следующий синтаксис:
Использование инструкции ALTER SCHEMA показано в примере ниже:
Здесь изменяется схема HumanResources базы данных AdventureWorks2012, перемещая в нее таблицу ContactType из схемы Person этой же базы данных. Инструкцию ALTER SCHEMA можно использовать для перемещения объектов между разными схемами только одной и той же базы данных. (Отдельные объекты в схеме можно изменить посредством инструкции ALTER TABLE или ALTER VIEW.)
Инструкция DROP SCHEMA
Для удаления схемы из базы данных применяется инструкция DROP SCHEMA. Схему можно удалить только при условии, что она не содержит никаких объектов. Если схема содержит объекты, попытка выполнить инструкцию DROP SCHEMA будет неуспешной.
Как указывалось ранее, владельца схемы можно изменить посредством инструкции ALTER AUTHORIZATION, которая изменяет владение сущностью. Язык Transact-SOL не поддерживает инструкции CREATE AUTHORIZATION и DROP AUTHORIZATION. Владелец схемы указывается с помощью инструкции CREATE SCHEMA.
База данных: как ее создавать, с чего начать и основные этапы
С чего всегда начинается создание базы данных? С продумывания ее схемы. Схема базы данных — это ее структурная схема, внутри которой будет располагается сохраняемая информация. То есть это не сама информация, а лишь перечень и иерархия таблиц, в которых она сохраняется.
База данных нужна для того , чтобы сохранять информацию с веб-ресурсов и выдавать ее по запросу. Запросы могут исходить от пользователей веб-ресурсов, администраторов или браузера. При этом базы данных используются не только в программировании. В каждом другом случае, когда нужно структурировать большие объемы информации, присутствует возможность использовать БД.
Базы данных состоят из таблиц. В БД может располагаться одна таблица или их множество. Количество таблиц будет строго зависеть от автора или пользователя базы данных, а также от количества сохраняемой информации.
С чего начинается создание БД: схема базы данных
-
Microsoft SQL Server;
-
Oracle Database;
-
PostgreSQL;
-
MySQL;
-
SQLite;
-
и др.
-
LibreOffice Base;
-
OpenOffice.org Base;
-
Microsoft Access.
Схема базы данных — это основа
-
необходимое количество таблиц, чтобы сохранять всю важную и неважную информацию;
-
налаженные взаимосвязи между таблицами.
-
логического,
-
физического.
Логическая схема базы данных
Логическая схема базы данных — это организация логического взаимодействия отдельных таблиц внутри одной БД. В такой схеме присутствуют инструменты, которые иллюстрируют отношения между разными элементами базы данных. Другими словами, проектирование такой схемы баз ы данных происходит при помощи моделирования сущности отношений между информацией.
Такая схема нужна , чтобы легко моделировать поток информации по разным таблицам. Это делает информацию доступной для пользователей на каждом отдельном этапе использования веб-ресурса.
Физическая схема базы данных
Если логическая схема базы данных основывается на логике взаимоотношений между таблицами, тогда физическая основывается на физическом представлении БД. То ест ь ф изическая схема включает в себя варианты хранения информации на жестких дисках , а также варианты реализации структуры хранения при помощи языка программирования, например SQL.
То ест ь ф изическая схема включает в себя сервер ы для хранения информации, названия таблиц, названия отдельных столбцов и ячеек таблиц и другое. А это значит, что физическая схема базы данных реализует логическую схему.
Как начинается создание БД при помощи простых инструментов
-
Этап п ервый — создание базы данных. Запустите программу и найдите «Мастера баз данных». Там кликните на пункт « С оздать новую базу данных». Формат БД будет «Firebird встроенная». В «мастере» будет еще один шаг, где откроется одно окно. Тут установите «галочку» в пункте «Открыть базу данных для редактирования» и нажмите «Готово». Далее вам будет предложено назвать и сохранить БД на компьютере.
-
Этап второй — редактирование базы данных. На данном этапе реализуется необходимое количество табли ц п од сохраняемую информацию. Принцип простой: один вид информации — одна таблица. Например , информация об учениках — одна таблица. Информация о преподавателях — другая таблица. Информация об изучаемых предметах — третья таблица. Чтобы немного облегчить этот этап , можно в окне редактора Б Д в ыбрать пункт «Создать таблицу в режиме дизайна». В этом случае откроются характеристики и свойства разных полей таблиц ы . Вам останется только правильно выбрать каждому полю соответствующее значение, например : «текст», «целое число» и др.
-
Этап третий — создание связей. На этом этапе реализуется логическая схема баз данных. На предыдущем этапе нужно было сформировать количество таблиц, опираясь на логическую схему. Чтобы установить связи , пройдите по пути в панели управления: «Сервис → Связи». Вам откроется окно для добавления связей. Добавьте таблицы, которые были созданы ранее и между которыми нужно наладить связь. Обычно у каждой таблиц ы присутствуют столбцы с идентификаторам и ( номер паспорта, артикул товара, id и др.) . Устанавливая связь между столбцами с идентификаторами разных столбцов , нужно кликнуть на соответствующий столбец одной таблицы и, не отжимая левую кнопку мыши, провести курсор до соответствующего столбца другой таблицы. Между столбцами таблицы появится «ломаная линия».
-
Этап четвертый — наполнение таблицы информацией. Откройте таблицу, которую нужно заполнить. Внимательно заполните ее всей необходимой информацией. Если в настройках столбца с идентификаторами выставить пункт «Автозначение», тогда он будет заполняться автоматическ и п о мере того, как будут наполняться информацией другие ячейки таблицы.
Заключение
С чего начинается создание БД? Первое , что продумывается , — это схема базы данных. А далее выбирается подходящий инструмент: профессиональные или упрощенные СУБД , после чего создается база данных. На словах звучит все достаточно просто. На деле же придется потрудит ь ся и разобраться с СУБД, потому что даже упрощенные подобные программы обладают большим набором разного инструмента, который изначально сбивает с толку.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Схема базы данных
Схема базы данных включает в себя описания содержания, структуры и ограничений целостности, используемые для создания и поддержки базы данных [1] .
Постоянные данные в среде базы данных включают в себя схему и базу данных. Система управления данными использует определения данных в схеме для обеспечения доступа и управления доступом к данным в базе данных [1] .
Содержание
Схема как структура базы данных
Схема системы базы данных (от англ. Database schema) — её структура, описанная на формальном языке, поддерживаемом системой управления базами данных (СУБД). В реляционных базах данных схема определяет таблицы, поля в каждой таблице, а также отношения между полями и таблицами.
Схемы в общем случае хранятся в словаре данных. Хотя схема определена на языке базы данных в виде текста, термин часто используется для обозначения графического представления структуры базы данных. [2]
Основными объектами схемы являются таблицы и связи.
Схема как объект базы данных
Есть и другое понятие схемы в теории баз данных.
Схема (SCHEMA) [3] — является одним из основных объектов базы данных Oracle. Близкое понятие (RIS Schema) существует в RIS-интерфейсе доступа к базам данных. SCHEMA также появилась и в Microsoft SQL Server 2005 и формально определяется как набор объектов в базе данных [4] .
В Oracle она привязывается только к одному пользователю (USER) и является логическим набором объектов базы данных. Схема создается при создании пользователем первого объекта, и все последующие объекты созданные этим пользователем становятся частью этой схемы.
Она может включать другие объекты, принадлежащие этому пользователю:
- таблицы,
- последовательности,
- хранимые программы,
- кластеры,
- связи баз данных,
- триггеры,
- библиотеки внешних процедур,
- индексы,
- пакеты,
- хранимые функции и процедуры,
- синонимы,
- представления,
- снимки,
- объектные таблицы,
- объектные типы,
- объектные представления.
Существуют и подобъекты схемы, такие как:
- столбцы: таблиц и представлений,
- секции таблиц,
- ограничения целостности,
- триггеры,
- пакетные процедуры и функции и другие элементы, хранимые в пакетах (курсоры, типы и т. п).
Существуют объекты не зависимые от схемы
- каталоги,
- профили,
- роли,
- сегменты,
- табличные области
- пользователи.
Уровни схемы базы данных
- Концептуальная схема — карта концепций и их связей
- Логическая схема — карта сущностей и их атрибутов и связей
- Физическая схема — частичная реализация логической схемы
- Схема объекта — объект БД Oracle
Примечания
- ↑ 12 ГОСТ Р ИСО МЭК ТО 10032-2007: Эталонная модель управления данными (идентичен ISO/IEC TR 10032:2003 Information technology — Reference model of data management)
- ↑What is schema? — A Word Definition From the Webopedia Computer Dictionary
- ↑Основные объекты Oracle — Книги по базам данных
- ↑Схемы баз данных SQL Server 2005, разделение пользователей и схем — AskIt.RU
См. также
- Моделирование данных
- Моделирование данных
- Базы данных
- Теоретические основы баз данных
Wikimedia Foundation . 2010 .
Полезное
Смотреть что такое «Схема базы данных» в других словарях:
Схема базы данных — 53. Схема базы данных Data base scheme Описание базы данных в контексте конкретной модели данных Источник: ГОСТ 20886 85: Организация данных в системах обработки данных. Термины и определения … Словарь-справочник терминов нормативно-технической документации
концептуальная схема базы данных — концептуальная схема Схема базы данных, определяющая представление базы данных, единое для всех ее приложений и не зависящее от используемого в системе управления этой базой данных представления данных в среде хранения и путей доступа к ним.… … Справочник технического переводчика
Концептуальная схема базы данных — 56. Концептуальная схема базы данных Концептуальная схема Conceptual scheme Схема базы данных, определяющая представление базы данных, единое для всех ее приложений и не зависящее от используемого в системе управления этой базой данных… … Словарь-справочник терминов нормативно-технической документации
внешняя схема базы данных — внешняя схема Схема базы данных, поддерживаемая системой управления базы данных для приложений. [ГОСТ 20886 85] Тематики организация данных в сист. обраб. данных Синонимы внешняя схема EN external scheme … Справочник технического переводчика
Внешняя схема базы данных — 54. Внешняя схема базы данных Внешняя схема External scheme Схема базы данных, поддерживаемая системой управления базы данных для приложений Источник: ГОСТ 20886 85: Организация данных в системах обработки данных. Термины и определения … Словарь-справочник терминов нормативно-технической документации
внутренняя схема базы данных — внутренняя схема Схема базы данных, определяющая представление данных в среде хранения и пути доступа к ним. [ГОСТ 20886 85] Тематики организация данных в сист. обраб. данных Синонимы внутренняя схема EN internal scheme … Справочник технического переводчика
Внутренняя схема базы данных — 55. Внутренняя схема базы данных Внутренняя схема Internal scheme Схема базы данных, определяющая представление данных в среде хранения и пути доступа к ним Источник: ГОСТ 20886 85: Организация данных в системах обработки данных. Термины и… … Словарь-справочник терминов нормативно-технической документации
Распределенные базы данных — Распределённые базы данных (РБД) совокупность логически взаимосвязанных баз данных, распределённых в компьютерной сети. Основные принципы РБД состоит из набора узлов, связанных коммуникационной сетью, в которой: а)каждый узел это полноценная СУБД … Википедия
Распределённые базы данных — В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия
Схема — Схема: графический документ [1]; изложение, изображение, представление чего либо в самых общих чертах, упрощённо (например, схема доклада)[2]; электронное устройство, содержащее множество компонентов (интегральная схема). Графический документ… … Википедия
Скромное руководство по схемам баз данных
Для приложений, которые будут масштабироваться по трафику и сложности, крайне важно изначально спроектировать грамотную схему базы данных. Если сделать плохой выбор, придется потратить много усилий, чтобы этот плохой шаблон не распространился на службы и контроллеры бэкендов и, наконец, на фронтенд.
Но как оценить, какая схема лучше? И что вообще значит «лучше», когда мы говорим об архитектуре БД? Команда Mail.ru Cloud Solutions предлагает познакомиться с рекомендациями Майка Алча, консультанта по разработке программного обеспечения. Нам кажется, что он довольно лаконично резюмировал некоторые принципы грамотной архитектуры.
Директор: «Думаю, мы должны построить базу данных SQL».
Разработчик (он вообще понимает, о чем говорит, или просто увидел какую-то рекламу в бизнес-журнале. ): «Какого цвета хотите базу данных?».
Директор: «Пожалуй, у сиреневого больше всего памяти».
Несколько базовых советов
Итак, важно стремиться к двум основным вещам:
- При разбиении информации по таблицам сохраняется вся информация.
- Избыточность хранения минимальна.
Вот некоторые рекомендации, которые помогут приблизиться к хорошей архитектуре:
- Используйте как минимум третью нормальную форму (в которой каждый неключевой атрибут «должен предоставлять информацию о ключе, полном ключе и ни о чем, кроме ключа», согласно формулировке Билла Кента).
- Создайте последнюю линию обороны в виде ограничений.
- Никогда не храните в одном поле целые адреса.
- Никогда не храните в одном поле имя и фамилию.
- Установите соглашения для имен таблиц и полей и придерживайтесь их.
— Над чем работаешь?
— Оптимизирую этот SQL-запрос. Он тормозит, и пользователи начинают жаловаться.
— А нецензурная лексика в комментариях обязательна для оптимизации?
— Если бы ты видел оригинальный код, то не спрашивал бы.
Рассмотрим эти рекомендации подробнее.
1. Используйте как минимум третью нормальную форму
Архитектуру баз данных можно разделить на следующие категории:
- Первая нормальная форма.
- Вторая нормальная форма.
- Третья нормальная форма.
- Нормальная форма Бойса-Кодда.
Первая нормальная форма
Для первой нормальной формы каждое значение каждого столбца каждой таблицы в БД должно быть атомарным. Что значит атомарным? Если вкратце, атомарное значение представляет собой «единичную вещь».
Например, у нас есть такая таблица:
first_name | last_name | age | areas |
Jhon | Doe | 27 | |
Mary | Jane | 33 | |
Tom | Smith | 35 |
Здесь столбец areas («Области») содержит значения, которые не являются атомарными. Например, в строке Джона Доу поле хранит две сущности: «Дизайн веб-сайтов» и «Исследование клиентуры».
Таким образом, эта таблица не находится в первой нормальной форме.
Чтобы привести ее к такой форме, в каждом поле должно храниться только одно значение.
Вторая нормальная форма
Во второй нормальной форме ни один столбец, который не является частью первичного ключа (или который может действовать как часть другого первичного ключа), не может быть выведен из меньшей части первичного ключа.
Допустим, у вас такая архитектура базы (я подчеркнул поля, соответствующие первичному ключу в этой таблице):
employee_id | project_id | Hours | employee_name | project_name |
1 | 1 | 10 | Джон | “дизайн веб-сайта” |
2 | 1 | 20 | Мэри | “дизайн веб-сайта” |
В этом проекте имя сотрудника может быть непосредственно выведено из employeee_id, поскольку идея заключается в том, что имя сотрудника однозначно определяется его идентификатором.
Аналогично, имя проекта однозначно определяется идентификатором project_id.
Таким образом, у нас два столбца можно вывести из части первичного ключа.
Каждого из этих примеров было бы достаточно, чтобы выбросить эту таблицу из второй нормальной формы.
Еще один вывод заключается в том, что если таблица была в первой нормальной форме и все первичные ключи являются одиночными столбцами, то таблица уже находится во второй нормальной форме.
Третья нормальная форма
Чтобы таблица соответствовала третьей нормальной форме, она должна быть во второй нормальной форме, при этом в ней не должно быть атрибутов (столбцов), кроме первичного, которые транзитивно зависят от первичного ключа.
Допустим, у вас следующая архитектура (которая далека от идеала):
employee_name | employee_id | age | department_number | department_name |
Джон | 1 | 27 | 123 | “Маркетинг” |
Мэри | 2 | 33 | 456 | “Оперативный” |
Том | 3 | 35 | 123 | “Маркетинг” |
В этой таблице department_number можно вывести из employee_id, а department_name можно вывести из department_number. Таким образом, department_name транзитивно зависит от employee_id!
Если существует такая транзитивная зависимость: employee_id → department_number → department_name, то данная таблица не находится в третьей нормальной форме.
Какие проблемы возникают из-за этого?
Если название отдела можно вывести из его номера, то хранение этого поля для каждого сотрудника вводит лишнюю избыточность.
Представьте, что отдел маркетинга меняет название на «Маркетинг и продажи». Чтобы сохранить согласованность, придется обновить ячейку в каждой строке таблицы для каждого сотрудника этого отдела! В третьей нормальной форме такого бы не произошло.
Кроме того, вот, что произойдет, если Мэри решит покинуть компанию: мы должны удалить ее строку из таблицы, но если она была единственным сотрудником оперативного отдела, то отдел тоже придется удалить.
Всех этих проблем можно полностью избежать в третьей нормальной форме.
Мамины эксплойты. Ее дочь зовут Помогите! Меня заставляют подделывать паспорта
2. Создайте последнюю линию обороны в виде ограничений
База данных, с которой вы работаете, — это больше, чем просто группа таблиц. В нее встроена определенная функциональность. Многие из этих функций помогают обеспечить качество и корректность данных.
Ограничения устанавливают правила, какие значения можно вносить в поля БД.
Когда определяете отношения в базе данных, обязательно установите ограничения внешних ключей.
Обязательно укажите, что должно произойти при удалении и обновлении строки, связанной с другими строками в других таблицах (правила ON DELETE и ON UPDATE).
Обязательно используйте NOT NULL для всех полей, которые никогда не должны обнуляться. Возможно, есть смысл установить проверку на бэкенде, но помните, что сбои случаются всегда, поэтому не помешает добавить и такое ограничение.
Установите проверочные ограничения CHECK, чтобы убедиться — значения таблицы находятся в допустимом диапазоне, например, цена на товар всегда имеет положительное значение.
Интересный факт: в апреле 2020 года именно такое ограничение в программном обеспечении помешало торгам на московской бирже ММВБ, потому что цена на нефтяные фьючерсы WTI опустилась ниже нуля. В отличие от московской биржи, Нью-Йоркская товарная биржа NYMEX обновила софт за неделю до инцидента, поэтому сумела успешно провести сделки по отрицательной цене, то есть с доплатой покупателю от продавца — прим. пер.
Обо всех ограничениях PostgreSQL можно почитать здесь.
3. Никогда не храните в одном поле целые адреса
Если в вашем приложении или на веб-сайте есть форма с одним полем, где пользователь вводит свой адрес, то это уже плохо пахнет. Очень вероятно, что в этом случае у вас будет также одно поле в базе данных для хранения адреса в виде простой строки.
Но что делать, если нужно объединить покупки клиентов по городам, чтобы посмотреть, в каком городе какой продукт более популярен? Вы сможете это сделать?
Это будет очень тяжело!
Поскольку полный адрес хранится как строка в поле БД, в первую очередь придется разбираться, какая часть этой строки является городом! И это почти невыполнимая задача, учитывая все возможные форматы адресов в этом поле.
Поэтому обязательно разбивайте универсальное поле «Адрес» на конкретные поля: улица, номер дома, город, область, почтовый индекс и так далее.
Еще одна проблема адресов — «анонимные» поля
Вот иллюстрация из книги Майклза Блаха «Медная пуля для улучшения качества программного обеспечения»:
Какие тут видны возможные проблемы? Сможете ли вы легко отличить город Чикаго от улицы Чикаго? Наверное, нет.
Поэтому не забывайте всегда давать четкие имена столбцов каждой единице информации.
Как составлять резюме
— У тебя есть опыт в SQL?
— Так и пиши: эксперт по NoSQL.
4. Никогда не храните в одном поле имя и фамилию
Аналогично ситуации с адресами: количество вариаций имени и фамилии слишком велико, чтобы их четко различать.
Конечно, можно отделить имя от фамилии, если между ними пробел.
Например, «Майк Альче» → имя «Майк» и фамилия «Альче».
Но что делать, если пользователь ввел второе имя? Или у него двойная фамилия? А что, если есть и второе имя, и двойная фамилия?
Как определить, где имя, а где фамилия, чтобы разделить строку? Ошибки неизбежны.
Способ избежать многих проблем — создать отдельные поля (в формах) для имен пользователей first_name и last_name. Таким образом, вы позволите пользователям разделить свои собственные имена и сможете хранить данные согласованным образом.
Примечание: я не говорю, что в полях БД запрещены пробелы. Например, для таких имен, как «Хуан Мартин Дель Потро», первая часть «Хуан Мартин» входит в поле first_name, а «Дель Потро» — в поле last_name. Конечно, это не идеально. Можно дополнительно завести столбцы middle_name и second_last_name. Посмотрите подробнее о возможных вариациях имен и фамилий в списке «Заблуждения программистов об именах» и статье «Заблуждения программистов об именах — с примерами». Придется согласиться на какой-то компромисс между точностью и практичностью.
5. Установите соглашения для имен таблиц и полей и придерживайтесь их
Довольно неприятно работать с данными, которые выглядят как user.firstName, user.lst_name, user.birthDate и так далее.
Я бы посоветовал установить правила именования с подчеркиванием, потому что не все SQL-движки одинаково обрабатывают заглавные буквы, а заключать всё в кавычки весьма утомительно.
Выберите так же, как называть таблицы — во множественном или единственном числе (например, users во множественном числе или user в единственном). Мне больше нравится единственное число, но все фреймворки для бэкенда, кажется, по умолчанию настроены на множественное. Приходится следовать шаблону и использовать множественное число.