Нормализация базы данных, которая импортируется/экспортируется много

Question

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

База данных будет импортирована/экспортирована с одного сервера на другой и обратно. Кроме того, одновременно будет несколько событий.

Чтобы объяснить проблему, с которой я столкнулся при разработке этой системы, предположим, что существуют два отдельных события (A и B). На онлайн-сервере гости могут зарегистрироваться для этих событий. В какой-то момент времени произойдет событие A, поэтому я должен экспортировать базу данных на автономный сервер для использования на месте. Между тем, гости все еще могут зарегистрироваться в Интернете для мероприятия B. На месте мероприятия A можно зарегистрировать также событие A, но не для события B.

После события A конец будет практически невозможно импортировать в автономный режим базы данных в онлайн, без какого-либо изменения данных. Я предположил, что у меня, вероятно, есть два варианта для схемы базы данных:

1. Нормализовать полностью: есть таблица гостей со значком event_id. Все остальные таблицы, зависящие от гостей или событий, будут просто ссылаться на первичный ключ гостя и/или события.
2. Раздельные столы между событиями: Есть столы для гостей A_guests и B_guests. Все остальные таблицы, зависящие от гостей или событий, также будут указаны в соответствии с событием.

Импорт и экспорт будет очень простым с выбором 2 (и без изменения данных), но количество таблиц будет расти очень быстро. Это в значительной степени дилемма: нормализовать, но испытывать трудности с импортом/экспортом. Или разделите таблицы и умножьте количество таблиц быстро.

У меня отсутствует опция, или вы считаете, что один из этих вариантов лучший выбор?

Answer 1

В какой-то момент времени произойдет событие A, поэтому я должен экспортировать базу данных на автономный сервер для использования на месте. Между тем, гости все еще могут зарегистрироваться в Интернете на мероприятие B. На месте на мероприятии A также можно зарегистрироваться.

Я хочу быть уверенным, что это понимаю. В какой-то момент вы экспортируете базу данных на автономный сервер для события A. Гости больше не могут регистрироваться для участия в онлайн-мероприятии, но могут зарегистрироваться только на сайте A. Это правильно? Если это так, то проблема не возникает, если онлайн-программное обеспечение узнает об экспорте.

На мероприятии A вы хотите, чтобы гости зарегистрировались на мероприятие B. Это правильно? Потому что, если это так, вам придется в конечном итоге передать эти B-транзакции обратно в вашу онлайн-базу данных, и я полагаю, надеюсь, что вы не забудете B. С 2 или более копиями базы данных у вас нет механизма для предотвращения овербукинг.

У меня отсутствует опция, или вы считаете, что один из этих вариантов лучший выбор?

Вы хотите нормализовать свою базу данных бронирования полностью. Событие A должно иметь копию всей базы данных бронирования, если вы хотите разрешить людям регистрироваться на событие B или C или D и т. Д. На мероприятии A.

Единственная проблема, которую я вижу, это проблема переупорки, так как у вас есть все эти копии базы данных на разных событиях.