На что обращал внимание при создании таблиц в БД

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

Первое и главное — нормализация, ёпта. Это не какая-то заумь, а просто правило: не тащи в одну кучу всё подряд. Каждая таблица — это одна сущность. Заказы — отдельно, клиенты — отдельно, товары в заказе — отдельно. Если видишь, что повторяешь одни и те же данные в десяти строках (типа адрес клиента в каждом его заказе), значит ты уже накосячил. Разделяй. Цель — чтобы данные об одном факте хранились в одном месте. Иначе потом будешь пол-базы апдейтить, когда что-то поменяется.

Ключи, блядь. Если делаешь простой числовой ID, который просто увеличивается, — бери IDENTITY. Это стандарт де-факто. Если система распределённая, где данные создаются в разных местах и потом стыкуются, тогда уже GUID (UNIQUEIDENTIFIER). Но с ним тоже свои грабли — размер индексов ебёт не по-детски.

Типы данных — вот где народ реально обсирается. Не храни числа в VARCHAR, ёб твою мать! Для целых чисел — INT, BIGINT. Для строк с русским/китайским/каким угодно текстом — NVARCHAR. И забудь про устаревшие типы вроде TEXT или NTEXT — они deprecated, как твои шансы на повышение, если их используешь.

Индексы — это палка о двух концах. Надо навешивать на поля, по которым часто ищешь (WHERE, JOIN). Но если навешаешь их как дурак на каждую колонку, то запись новых данных будет тормозить так, что мама не горюй. Каждый индекс — это дополнительная работа при вставке или обновлении. Баланс, блядь, нужен.

Ограничения (CONSTRAINTS) — твои лучшие друзья. Они не дадут запихнуть в базу какую-нибудь дичь. NOT NULL — поле обязательно к заполнению. UNIQUE — значение должно быть уникальным. FOREIGN KEY — связывает таблицы и не даст удалить запись, на которую кто-то ссылается. CHECK — можно, например, проверить, что email содержит собаку. Это валидация на уровне базы, и она железобетонная. На неё можно положиться.

Названия. Не называй таблицы Tbl1, Tbl2 или DataFinalFinal2. Называй понятно: Users, Orders, OrderItems. Выбери один стиль именования — либо snake_case, либо CamelCase — и придерживайся его до конца. Иначе через полгода сам в своей же схеме не разберёшься.

Вот тебе живой пример, как это выглядит в коде:

CREATE TABLE Users (
    UserId INT PRIMARY KEY IDENTITY(1,1),
    Username NVARCHAR(50) NOT NULL UNIQUE,
    Email NVARCHAR(100) NOT NULL CHECK (Email LIKE '%@%.%'),
    CreatedAt DATETIME DEFAULT GETDATE()
);

Смотри: UserId — первичный ключ, сам растёт. Username — строка, обязательно, и уникальная. Email — тоже строка, и проверка, что там есть собака и точка (примитивно, но работает). CreatedAt — дата создания, по умолчанию ставится текущая.

А ещё, если таблица планируется овердохуища большая (миллионы-миллиарды строк), с самого начала думай про партиционирование. И комментируй поля, если они неочевидные. Поверь, твоему будущему себе или коллеге будет за это огромное спасибо, а не желание впендюрить тебе вилкой в глаз.