Как лучше организовать структуру БД?
Есть игра, в которой есть герои. Каждый герой говорит свою случайную фразу. Все фразы героев хранятся в БД.
Надо организовать структуру БД - т.е. создать в БД таблицу/таблицы с фразами, для каждого героя.
Первое что приходит на ум - Одна таблица для всех героев с 3 полями
id - автоинкремент
имя героя
фраза героя
И далее, делать выборку по имени героя, для каждого героя.
Но есть "проблема". При добавлении новой фразы для героя, она всегда будет в конце таблицы т.к. это новая запись.
Т.е. при дополнении таблицы фразами - для 1 героя, для второго, придумали новую фразу для 1 героя, они будут идти в разнобой. Это визуально не удобно для отслеживания, понимания, не красиво.
Да, в менеджерах БД есть визуальная сортировка-клик по полю (можно и запросом) но это лишние действия, а когда проект большой, лучше делать всё проще и без лишних действий (серьезно - после 6 часов работы случайный клик не туда и вот работа на следующий день).
Вариант 2. Для каждого героя своя таблица. Таблица Hero1 Hero2 и т.д.
id - автоинкремент
фраза героя
И далее, делать выборку всех записей из таблицы т.к. в ней фразы для нужного героя.
Просто, интуитивно понятно, все фразы идут "друг за другом", но много таблиц.
Дополнительно:
сделать таблицу с героями, сделать таблицу с фразами, и тупо сделать связь многие ко многим используя промежуточную таблицу
так как одна и та же фраза - может быть у нескольких героев, и так как один герой - может иметь несколько фраз
Ответы:
С точки зрения адекватного проектирования баз данных — однозначно первый вариант (и, желательно, с индексом по имени героя). А если очень хочется просматривать отдельные выборки по героям без дополнительных действий — использовать для этого такую штуку как Views, если база их поддерживает и позволяет редактировать. Но вообще, во всех нормальных менеджерах баз данных есть возможность выборки с фильтрацией по содержимому поля, и лучше использовать их.
Но есть "проблема". При добавлении новой фразы для героя, она всегда будет в конце таблицы т.к. это новая запись.
Т.е. при дополнении таблицы фразами - для 1 героя, для второго, придумали новую фразу для 1 героя, они будут идти в разнобой. Это визуально не удобно для отслеживания, понимания, не красиво.
Это не проблема. При выборке фраз ты можешь спокойно указать нужный порядок.
База данных - это не эксель, и даже в экселе это не было бы проблемой благодаря сортировкам.
Первое что приходит на ум - Одна таблица для всех героев с 3 полями
id - автоинкремент
имя героя
фраза героя
Лучше для героев завести отдельную таблицу, а в этой таблице держать только id героя.
Вариант 2. Для каждого героя своя таблица. Таблица Hero1 Hero2 и т.д.
id - автоинкремент
фраза героя
И далее, делать выборку всех записей из таблицы т.к. в ней фразы для нужного героя.
Просто, интуитивно понятно, все фразы идут "друг за другом", но много таблиц.
Из такой базы нереально будет программно вытаскивать данные.
Тебе придётся для каждого героя свой запрос заводить и кучу запросов у которых различается только имя таблицы.
Такие запросы даже шаблонизировать не получиться, тк подготовленные запросы в бд только с аргументами работают, а имя таблицы аргументом не является.
Тебе должно быть пофиг, как эти данные структурируются с точки зрения человека.
Структурируй с точки зрения запросов и программы, которая будет с этими данными работать.
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
Для оптимальной организации структуры базы данных (БД) следует учитывать несколько ключевых аспектов, таких как эффективность запросов, нормализация данных, удобство использования и поддержки, а также возможность масштабирования.
Во-первых, рекомендуется использовать нормализованную структуру данных, чтобы избежать избыточности информации и обеспечить целостность данных. Нормализация помогает снизить объем хранимой информации и упрощает обновление данных. Для этого можно разделить данные на отдельные таблицы и связать их между собой с помощью внешних ключей.
Пример структуры БД с нормализацией данных:
Таблица "users": - id (PRIMARY KEY) - name - email Таблица "posts": - id (PRIMARY KEY) - title - content - user_id (FOREIGN KEY references users.id)
Во-вторых, важно правильно индексировать таблицы для оптимизации производительности запросов. Индексы позволяют быстро находить нужные записи в таблице. Необходимо добавлять индексы к полям, по которым часто выполняются запросы (например, поиск по id или email).
Пример добавления индекса к полю "email" в таблице "users":
CREATE INDEX idx_email ON users(email);
Также важно учитывать потребности приложения и специфику бизнес-логики при проектировании структуры БД. Необходимо анализировать типы запросов, которые будут выполняться чаще всего, и оптимизировать структуру данных под них.
Например, если приложение часто выполняет запросы на выборку данных определенного пользователя, то имеет смысл добавить дополнительные индексы или денормализовать данные для ускорения выполнения запросов.
В общем, при проектировании структуры БД важно учитывать требования к производительности, нормализацию данных, индексацию таблиц и специфику бизнес-логики приложения. Следуя этим рекомендациям, можно создать эффективную и удобную структуру базы данных для вашего проекта.