Как я должен делать версии своих данных в среде общего сервера MS SQL?

Question

Сервер является общим хостинг-сервером Windows с Hostgator.Нам разрешено использовать «неограниченные» базы данных MS SQL, а каждой из них разрешено «неограниченное» пространство.Я пишу сайт на PHP.Данные (не схема БД, а данные) должны быть версионированы таким образом, чтобы (в идеале) мой клиент мог выбрать желаемую версию БД из поля выбора при входе на веб-сайт, а затем (примерно раз в месяц)пометить текущие данные, также через простую форму на сайте.Я подумал о нескольких теоретических способах сделать это, и я не в восторге ни от одного из них.

1) Поместите столбец VersionNumber в каждую таблицу;иметь основную таблицу версий, в которой перечислены все версии для поля выбора при входе в систему.При пометке каждая строка без номера версии в каждой таблице в БД будет дублироваться, а оригиналу будет присвоен номер версии.

Это кажется самой простой идеей и для меня, и для моего клиента, но яЯ обеспокоен тем, что БД будет ужасно медленной всего через несколько месяцев, поскольку каждая таблица будет увеличиваться (по крайней мере) по сравнению с ее первоначальным размером каждый месяц.Там не так много данных, и, вероятно, никогда не будет, ни в одной версии.Но умножение версий в одной и той же таблице меня просто пугает.

2) Дублируйте БД каждый раз, когда мы помечаем теги.

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

3) Создавайте дубликаты таблиц (с версией в их названии) внутри одной и той же базы данных каждый раз, когда мы помечаем теги.Как и [v27_Employee].

Преимущество по сравнению с идеей (1) состоит в том, что ни одна таблица не станет огромной по размеру, что позволит запросам поддерживать свою скорость, а по идее (2) это можно теоретически сделатьлегко через простую форму тега сайта, а не вручную моим клиентом.Проблемы заключаются в том, что запросы в моем PHP-коде будут смущены, поскольку я пытаюсь объяснить, с какой таблицей Employee соединяется какая таблица адресов, в зависимости от того, какая версия выбрана, поскольку все они имеют одно и то же имя, но разные;а также то, что при изменении кода старые таблицы БД больше не совпадают, такая же проблема, как (2).

Итак, наконец, есть ли у кого-нибудь хорошие рекомендации?Лучшие практики?То, что они делали, работали в прошлом?

Спасибо, ребята.

Answer 1

Вы можете копировать свои таблицы версий в новую базу данных каждый месяц.Если вам нужно выполнить соединение между таблицей с поддержкой версий и таблицей без возможности управления версиями, вам необходимо выполнить объединение между схемами, которое поддерживается в SQL Server.Этот подход немного чище, чем дублирование таблиц в одной схеме, так как ваш обозреватель баз данных станет громоздким со всеми старыми таблицами.

Answer 2

В конечном итоге я создал новую схему для каждой версии и дублировал таблицы, триггеры и ключи при каждой версии БД. Так, например, у меня была эта таблица:

[dbo].[TableWithData]

И я скопировал его в эту таблицу в той же БД:

[v1].[TableWithData]

Затем, когда пользователь хочет просмотреть старые таблицы, он выбирает, какая версия и мой код автоматически меняет каждый экземпляр [dbo] в каждом запросе на [v1]. Это концептуально довольно просто, и пользователю не нужно делать ничего сложного с версией - просто введите «v1» в форму и нажмите кнопку отправки. Мой PHP и SQL делают все остальное.

Я обнаружил, что некоторые таблицы должны были оставаться отдельными - я создал другую схему под названием [ctrl], в которую я поместил таблицы, которые не будут версионными, как, например, таблица имени пользователя / пароля. Таким образом, я просто дублирую [dbo] таблицы.

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

Answer 3

Вариант 1 является наиболее очевидным решением, поскольку он требует минимальных затрат на обслуживание и с ним проще всего работать: вы можете просмотреть любую версию в любое время, просто добавив @VersionNumber к своим запросам. Если вы хотите или нуждаетесь, это означает, что вы также можете одновременно реализовать вариант 3, создавая представления для каждого номера версии вместо реальных таблиц. Если ваше приложение запрашивает только одну версию за раз, рассмотрите возможность сделать VersionNumber первым столбцом кластерного первичного ключа, чтобы все данные для одной версии физически сохранялись вместе.

И еще не ясно, сколько у вас данных. Вы говорите, что это "не очень много", но это ничего не значит. Если у вас действительно много данных (скажем, в сотни миллионов строк) и если у вас есть Enterprise Edition (вы не сказали, какую версию вы используете), вы можете использовать разбиение таблиц для «разделения» очень больших таблиц для лучшей производительности.

Мой вывод будет заключаться в том, чтобы сделать самое простое и легкое в обслуживании прямо сейчас. Если это работает нормально, то все готово. Если этого не произойдет, вы по крайней мере сможете переработать свой дизайн с простой, стабильной отправной точки. Если вы сделаете что-то более сложное сейчас, у вас будет гораздо больше работы, если вам когда-нибудь понадобится изменить его.