Комментарии 11
Мало в каких подобных приложениях есть сравнение двух баз/таблиц. Не знаю насколько часто это нужно кому-то, но мне несколько лет назад очень нужно было, и единственное решение, которое я нашел это HeidiSQL, который в моем случае глючил довольно сильно.
Речь о функционале, когда можно выбрать две базы/таблицы и сравнить их, а как итог, получить SQL, который приведет вторую сравниваемую базу/таблицу к такой же структуре как первая, то есть добавит недостающие таблицы/столбцы, изменит тип столбцов, но не будет удалять текущие данные.
Речь о функционале, когда можно выбрать две базы/таблицы и сравнить их, а как итог, получить SQL, который приведет вторую сравниваемую базу/таблицу к такой же структуре как первая, то есть добавит недостающие таблицы/столбцы, изменит тип столбцов, но не будет удалять текущие данные.
Не всегда можно изменить тип столбцов без потери данных
Как раз сейчас занимаюсь такой задачей. Для SQL Server нет идеального решения, который сделал бы выгрузку структуры таблиц в SQL так же, как это делает SQL Server Management Studio (SSMS), с файловыми группами и секционированными функциями. Даже SSDT не умеет выгружать файловые группы в таблицах.
Не подскажете, HeidiSQL умеет выгружать таблицы в том же виде, что и SSMS?
Не подскажете, HeidiSQL умеет выгружать таблицы в том же виде, что и SSMS?
Если нужна точная копия таблицы, не лучше ли будет использовать drop, create, insert из дампа, вместо сравнения?
Понятно, что создание индексов займет достаточно много времени на больших объемах данных, но и сравнение в этом случае зависнет на долго.
Понятно, что создание индексов займет достаточно много времени на больших объемах данных, но и сравнение в этом случае зависнет на долго.
Если нет FOREIGN KEYS, то можно и пересоздать таблицу.
На счет индексов могу высказать свое мнение, на примере MSSQL:
1) если таблица небольшая, то можно создать индексы после заполнения таблицы,
2) если таблица занимает несколько Гб, то для создания кластеризованного индекса понадобится места столько же, сколько и сама таблица
Поэтому, предпочитаю, создавать индексы заранее на больших таблицах
На счет индексов могу высказать свое мнение, на примере MSSQL:
1) если таблица небольшая, то можно создать индексы после заполнения таблицы,
2) если таблица занимает несколько Гб, то для создания кластеризованного индекса понадобится места столько же, сколько и сама таблица
Поэтому, предпочитаю, создавать индексы заранее на больших таблицах
А зачем? Если база на допустим 50-100 гигов, заяем гонять эти данные туда сюда если надо добавить один/два столбца?
Ну и база может использоваться, на время выгрузок станет недоступной и могут потеряться данные
За это время данные полученные за время сравнения двух больших таблиц могут устареть, что тоже может стать проблемой.
Чтобы добавить два столбца, достаточно сравнивать только схемы и сгенерировать код.
Но тут опять в зависимости от используемой базы данных и кода приложения могут быть проблемы. Например, проверка в коде на не пустое поле, когда в это поле данные еще не импортировались из dev таблицы.
Чтобы вставить данные в пустые столбцы — достаточно импортировать их по ключевому полю из другой таблицы.
Возможная проблема при частичной синхронизации — поле не должно быть пустым, но т.к. запись проигнорирована при импорте, то редактирование заказа не возможно.
Все очень индивидуально, мне например не хватает просмотра миграций из фреймвоков, когда нужно посмотреть изменения не в виде кода приложения, а в виде sql запросов. Т.к. используемых фреймворков много и не всегда точно помнишь, что делать, приходится листать записи.
В функционале, скорее всего должны быть какие-то типовые операции, вида скопировать столбец из таблицы А в таблицу Б, с возможностью гибкой настройки и выполнения дополнительных операций необходимых для импорта.
Чтобы добавить два столбца, достаточно сравнивать только схемы и сгенерировать код.
Но тут опять в зависимости от используемой базы данных и кода приложения могут быть проблемы. Например, проверка в коде на не пустое поле, когда в это поле данные еще не импортировались из dev таблицы.
Чтобы вставить данные в пустые столбцы — достаточно импортировать их по ключевому полю из другой таблицы.
Возможная проблема при частичной синхронизации — поле не должно быть пустым, но т.к. запись проигнорирована при импорте, то редактирование заказа не возможно.
Все очень индивидуально, мне например не хватает просмотра миграций из фреймвоков, когда нужно посмотреть изменения не в виде кода приложения, а в виде sql запросов. Т.к. используемых фреймворков много и не всегда точно помнишь, что делать, приходится листать записи.
В функционале, скорее всего должны быть какие-то типовые операции, вида скопировать столбец из таблицы А в таблицу Б, с возможностью гибкой настройки и выполнения дополнительных операций необходимых для импорта.
Я написал модуль отслеживания изменения структуры БД на SQL сервер, так что проблем с просмотром истории, кто и что менял, теперь нет. Все что нужно, это создать триггер:
в котором нужно обрабатывать событие EVENTDATA(), подробности в этой статье
create trigger VersionControlTriggerName on all serverв котором нужно обрабатывать событие EVENTDATA(), подробности в этой статье
Red Gate SQL Comparer сравнивает для SQL Server отлично, Oracle есть. Как Вам нужно со скриптами и всем чем нужно. Также dbforge умеет это делать. Наберите в поисковике название нужной БД и слово Comparer, наверняка найдётся нужное. HeidiSQL для сравнения никогда не пользовал.
Добавлю, что есть отличные готовые решения как для сравнения по схемам баз данных, так и по самим данным.
Есть и бесплатные.
Сам пользуюсь решениями от компании Devart.
Самому компаратор написать весьма сложно и рутинно. Обычно такими вещами занимается специально выделенный для этого отдел и явно немаленькой компании.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Импорт/экспорт баз данных. Что нужно в подобных приложениях? Опрос