Репозиторий контроля версий для пользовательских данных

0

Какие инструменты или какие-либо руководства о том, как смоделировать мою схему mysql для хранения пользовательского контента в рамках контроля версий? Подобно репозиторию svn, но вместо кода мне нужно обновить все пользовательские объекты. Как и какие фотографии у пользователя есть 2 года назад в эту дату. Какие у него настройки и т.д. Да, я могу хранить резервные копии в таблицах, но проблема в том, что из-за разных видов объектов задействованы сотни и сотни таблиц. И я буду принимать shanpshots каждый день и теперь планирую реализовать его с каждым редактированием позже. Поэтому в основном мне интересно, как хранилище хранилищ svn хранит содержимое в базе данных или как окна хранят точки восстановления в некоторой базе данных, поэтому я могу имитировать эту модель для пользовательских данных. Единственное требование для меня - мне нужно использовать mysql для основной базы данных. как я вижу это:

Активные данные и исторические данные. Активные данные имеют текущую копию. Исторические данные индексируются по дате/времени. Но по-прежнему поддерживать сотни табличных данных для каждого пользователя каждый день, что означает 365 x количество пользователей x количество строк таблицы, которые мне нужны для версии. Я не знаю, может ли moeling его в mysql в 3NF лучше всего идти?

  • 0
    Похоже, вам нужно сначала провести рефакторинг схемы БД. Можете ли вы показать нам текущую схему?
Теги:
repository
version-control

2 ответа

0

Контроль версий - нетривиальная проблема. Он был решен множеством способов, но повторное его правильное решение далеко не тривиально. Эрик Санк пишет очень хороший блог о разработке своего собственного программного обеспечения для управления версиями, которое дает небольшую идею о сложности

Ваша конкретная проблема будет представлять собой объем данных, так как многие из ваших файлов будут бинарными, которые не будут эффективно храниться системами VC, поскольку они предназначены в основном для работы с текстом. Очень быстро, если у вас нет очень хорошего механизма diff, у вас будет слишком много данных для работы.

Мое предложение состояло бы в том, чтобы сконцентрироваться на взаимодействии с вашим программным обеспечением с чем-то, где кто-то уже сделал тяжелую работу, такую ​​как Subversion, Git, Mercurial или один из других превосходных инструментов управления версиями. Вы могли бы использовать их в качестве своего хранилища для хранения и версии всех файлов и создания своего программного обеспечения, чтобы понять все это.

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

Если вы все еще делаете это сами, вы можете сделать хуже, чем Eric Sinks Source Control How-To

Поделиться
0

Вы можете просто иметь поле timpstamp вместе с каждой записью базы данных. Затем сделайте ленивое удаление вместо удаления данных, то есть получите "удаленное" поле, которое снова может сохранить временную метку удаления. Эти сочетания позволят вам выполнять исторические запросы.

Когда вы сможете реализовать это из исторических снимков, вы можете оценить временную метку на основе первого/последнего моментального снимка, в котором вы видите запись и соответствующим образом изменяете записи базы данных.

Поделиться
  • 0
    Но как контролировать таблицы тогда? Возьмите детали своего профиля, например. он имеет 50 полей в 10 таблицах. Я беру Shapshot 365 дней, и у меня есть 10 миллионов пользователей. так через 1 год у меня будет 3 миллиарда и 650 миллионов строк на таблицу?
  • 1
    Вы сохраняете новую строку только тогда, когда происходит изменение. Как правило, гораздо реже, чем раз в день.
Показать ещё 1 комментарий

Ещё вопросы

Сообщество Overcoder
Наверх
Меню