Э… вопрос на маленькую конференцию.
20 лет назад ответ был бы "так, чтобы обеспечить их целостность" и соответственно в нормальной форме (было 5 нормальных форм и ещё нормальная форма Б-Н) - иногда для ответа в школе\универе этого хватает. Нормальные формы - это такие ограничения на уровне private-key \ foreign-key, что запись в зависимой таблице всегда относится к какой-то записи более базовой.
Потом, с резким ростом IT выяснилось, что SQL не удовлетворяет некоторым направлениям:
- скорость доступа к нормализированным данным (чтобы прочитать какие-то бизнес-данные надо было сделать много-много join, читая данные с диска) - так появились ненормализованные БД и в итоге key-value хранилища (типа Redis)
- недостаточно выразительности SQL, хочется прямо документ в Document Object Model хранить в базе - так появились NoSQL решения (типа MongoDB) или объект (так появились объектные хранилища - конкретных названий не будет, нет явного лидера)
- недостаточная скорость при определённом паттерне доступа (или недостаточная строгость в SQL-моделях), так появились решения типа Tarantool - когда вы данные не изменяете, а только добавляете новые записи
Ну и независимо от этого существуют архитектурные способы работы с БД (упомяну лишь самые базовые и необходимые):
- Поставить достаточно простую БД но всю логику вынести в app-server
- Ну и разумеется ORM-подход: когда вы обращаетесь к SQL-DB не при помощи SQL-запросов, а как к хранилищу объектов (таблица - набор объектов, PK-FK - ссылка из-на родительского объекта).
- Резюмирую:
20 лет назад ответ на ваш вопрос был бы (в универах он проходит иногда и сегодня) - в SQL-базах данных в нормализованной (одной из) форме.
Сегодня, если не нужно спец-решения то это тоже подойдёт. Если у вас есть конкретные и жёсткие требования - надо глубоко знать область.