В настоящее время я работаю над системой регистрации событий (в php). Он имеет две основные цели: зарегистрировать гостей онлайн до начала мероприятия и сканировать гостей на месте с помощью сканеров штрих-кода. Для этой системы важно иметь онлайн и автономный сервер, не все события будут иметь доступ к Интернету.
База данных будет много импортироваться / экспортироваться с одного сервера на другой и обратно. Кроме того, одновременно будет происходить несколько событий.
Чтобы объяснить проблему, с которой я столкнулся при разработке этой системы, давайте предположим, что есть два отдельных события (A и B). На онлайн-сервере гости могут зарегистрироваться для этих событий. В какой-то момент времени произойдет событие A, поэтому я должен экспортировать базу данных на автономный сервер для использования на месте. Между тем, гости все еще могут зарегистрироваться в режиме онлайн для проведения мероприятия B. На месте проведения мероприятия A можно зарегистрироваться и для мероприятия A, но не для мероприятия B.
После окончания события A будет практически невозможно импортировать автономную базу данных в оперативную, без какого-либо изменения данных. Я подумал, что у меня есть два варианта схемы базы данных:
- Нормализовать полностью: есть таблица гостей со свойством event_id. Все остальные таблицы, зависящие от гостей или событий, будут ссылаться только на первичный ключ гостя и / или события.
- Разделение таблиц между событиями: есть столы гостей A_ghest и B_ghest. Все другие таблицы, зависящие от гостей или событий, также будут названы в соответствии с событием.
Импорт и экспорт будут очень просты с выбором 2 (и без изменения данных), но количество таблиц будет расти очень быстро. Это в значительной степени дилемма: нормализовать, но есть трудности с импортом / экспортом. Или разделите таблицы, и количество таблиц будет увеличиваться очень быстро.
Я пропускаю опцию или вы считаете один из этих вариантов лучшим выбором?