Нужен штатный инструмент:
А). Объединение (слияние) двух и более баз данных.
Б). Перенос всех данных либо частичных из одной базы в другую.
Должны сохранятся привязки.
Это очень сложный инструмент, объём работы очень большой.
Опишите, пожалуйста, сценарий действия такого инструмента. В каких случаях необходимо объединять две базы? Базы настолько большие, что это невозможно сделать вручную?
Базы просто огромные в масштабе ручной работы, а именно (имеется две и более базы, планируется объединить все базы) каждая база содержит около 300 квартир и около 1000 приборов учёта.
Сценарий примерно следующий:
а. Полное слияние:
- на уровне бекапов (каждый бекап загружается в программу и на выходе один общий бекап)
- на уровне (т.к. две базы не запустить одновременно на одной машине то скорее всего вторая база будет опять же в виде бекапа или подключена по сети)
б. Частичное слияние: - на уровне бекапов (путём выбора какие записи перенести) на выходе так же общий бекап
- на уровне Lers путём выбора записей которые выгрузить и загрузить.
Я не совсем это имел в виду. Зачем вообще сливать две базы данных? Каким образом получились две огромные базы, которые необходимо соединить?
Если это единичный случай, то логичнее вам сделать программу на Lers Framework, которая будет решать задачу слияния конкретно ваших экземпляров. Это гораздо проще и логичнее, чем делать универсальный инструмент, который будет использован 1-2 раза.
не напрягайте разработчиков ЛЭРС бесмысленными инструментами, используйте готовые решения для мерджа баз или наймите программиста со знанием TSQL, он за 24 часа вам выполнить вашу задачу. Сам делал нечто подобное с базами правда Взлет СП…
PS: Google Code Archive - Long-term storage for Google Code Project Hosting.
А кто говорит о том что я напрягаю бессмысленно? Лично я считаю что в каждом нормальном ПО для работы с базой данных должно быть реализовано (backup, слияние, перенос и т.п. функции), то что вы предлагаете это уже костыли, и не факт что заработает как надо.
К тому же если вы так подкованы в этом вопросе почему бы вам самому не написать данную утилиту? Думаю она многим пригодилась бы!
ЛЭРС Учет это программа Энергетического комплекса, причем здесь БД SQL Server? Реализовать можно либо скриптом 1 раз это делается или же как выше сказано через Lers Framework. Это не будет “костылем” ибо вы выполняете данную процедуру исходя из своей потребности.
Как это образовалось! Изначально было два независимых объекта (в виду того что не было каналов связи) и соответственно на каждом доме был установлен свой сервер, после того как дома были переданы управляющей компании, которая желает видеть всё в одной базе. Дома вводятся поэтапно, на данный момент 6 домов (баз данных) и они будут всё только добавлятся и именно таким образом никак иначе. На подходе ещё три дома, и в ближайшем будущем ещё три.
В большинстве пользователи LERS используют для учёта объектов без квартирного учёта и соответственно думают что сложного в том что бы перенести один два объекта, а на самом деле это очень сложно, у нас начальный ввод данных занимает по одному дому от недели до двух.
Что касаемо сделать программу на Lers Framework, этот вариант очень неплохой но есть проблемыю Мы уже сталкивались с тем что просто часть функционала ещё просто не реализована см тема 1 и тема 2 а при переносе придётся создавать и привязывать (дом+домовые приборы+квартиры+квартирные приборы). К тому же программист у нас очень загружен и так.
Поверьте, наши программисты загружены ничуть не меньше. Реализация универсального инструмента - гораздо более трудозатратная работа.
При этом необходимо будет решить что делать при совпадении названий объектов, номеров объектов и точек учёта. Что делать с возможными совпадениями серийных номеров устройств, как обрабатывать перекрывающиеся данные, и так далее.
Инструмент, заточенный только под вашу задачу, написать гораздо проще, так как можно жёстко указать что делать в случае коллизий. Спцифику всех ваших серверов вы прекрасно знаете.
Добавить необходимые для вас функции в Lers Framework уже гораздо легче. По созданным вам темам я вижу, что вам ответили на оба ваших изначальных вопроса. Если возникают дополнительные вопросы, задавайте их в форуме, и функционал будет расширен по вашим требованиям.
Объясню более популярно как я это вижу:
- Вопрос дубликатов решается очень просто
- Главное уникальное поле ID к нему все привязки. При слиянии баз БД1 и БД2. Созадется новый элемент в промежуточной базе БД3 с параметрами записи БД2 - затем востанавливаются связи этого элемента путем добавления записей из БД2 в БД3 на основании нового ID. Главное чтобы ID новых элементов БД3 не перекрывали ID из БД1. А затем можно просто объединить БД1 и БД3 хоть простым переносом записей.
- В дубликатах серийных номеров нет ничего страшного, и поиск этих дубликатов проблема наладчика(не надо решать его работы) - в вашей программе два нажатия кнопок в таблице. У каждого устройства есть более важные параметры это идентификатор линии связи и сетевой адрес и ID точки учета привязанной к прибору.
- Реальные случаи дублирования у нас встречались в пределах одного дома пришлось переносить прибор в другой дом, ввиду ваших ограничений.
- В случае многоуровневой структуры
- Частичное объединение баз как в пункте 1.
- Сервер ЛЭРС в управляющей компании через вашу сетевую утилиту подтягивает только данные потребления SQL в SQL(можно даже средствами SQL) , например, только 1-2 отчета в сутки параметры для формирования месячного потребления.
- Основание обращения
- Конечно приятнее перенос данных было бы сделать средствами FrameWork дабы уйти от привязки к базе и её обновления и изменения структуры, однако, к сожалению функционал FrameWork(допилить придется) в текущей версии не позволит выполнить задачу полноценно (ссылки на темы в постах выше).
- Необходимую глубину объединения таблиц с полноценным пониманием структуры данных имеет только разработчик ПО, т.е. перенести минимально необходимый объем данных для стабильной работы приложения ЛЭРС.
Проблема даже не в этом основная, а в ключах таблиц: How to merge two databases in SQL Server? - Stack Overflow, свести 2 базы mssql в одну создает ряд проблем, они решаемы, но трудозатратны.
Присоединюсь к теме. Задача не настолько редкая. Если речь вести о миграции объектов из одной базы в другую. Речь вот об этом:
Конкретное применение - это централизация информации о потреблении. Т.е создается центральная городская система, где собираются данные по УК. У меня в 3-ех городах уже идут к этому. При этом центральная система ЛЭРСа часто не запрашивает данные напрямую с приборов, а собирает их с систем УК и т.п. Объемы работ при организации миграции действительно большие. При этом многие вопросы для утилиты решаются, если считать, что единицей информации будет объект. И после работы утилиты составить журнал работы, где отразить проблемы. Позже ручками можно все доделать.
Это не самая “горячая” задача, но актуальность ее с учетом изменений в законодательстве растет.
Решить ее можно и без разработчиков ЛЭРСа, но она будет возникать регулярно, поэтому я бы предложил ее поставить в план.
Вопрос поднимали устно уже давно, обсуждалась синхронизация подчинённых серверов с центральным обещали рассмотреть но я так понимаю до этой части руки и не дошли
Работа с базой данных - это функция SQL Server - СУБД. ЛЭРС Учет - это программа - транспорт и работа с приборными данными, отчетами, а не СУБД.
Подчеркну абсолютную ненужность предлагаемого функционала в ЛЭРС Учет. Ваша задача - единичный случай, решается написанием грамотного скрипта sql или реализация при помощи Framework.
Друзья, призываю к конструктивному диалогу с разработчиками и доведение ЛЭРС Учет по задач учета тепловой энергии, электричества и др ресурсов
Нам дам полный карт-бланш в виде Framework,API для реализаций собственных “надстроек” и “хотелок”, пользуйтесь ими.
Отчасти я с вами согласен, База данных это SQL, но что бы с нею работать надо знать структуру (вы её знаете?, если да то дайте нам и вопрос решён).
То же самое относится и к Framework (имеются готовые команды по миграции или синхранизации? думаю нету)
Вопрос единичный (выше Kvashnin так же интересуется данным вопросом, а значит уже не единичный) в силу того что мало кто вообще использует поквартирный учёт,
большинство используют LERS только для домового учёта и поэтому не видят проблем связных с поквартирным учётом.
А по поводу конструктивного диалога, кто вам сказал что я поднимаю данную тему просто ради праздного интереса, я так же заинтересован в улучшении продукта LERS,
и улучшатся он должен во всех частях (База данных, интерфейс ну и конечно же основные задачи, а именно учёт)
P.S. Если у вас уже имеются готовые скрипты SQL или в другой среде при помощи Framework, поделитесь все только будут вам признательны!
Структуру базы знаю. Готовых решений нет ибо не ставилась такая задача в нашем регионе. Сформируйте ТЗ с четким указанием как вам необходимо провести merge БД. На самом деле изначально эту задачу можно было решить другими путями, не представляю до конца вашу ситуацию, тоже обсуждаемо. В личных скинул свой mail.
Спасибо, я подготовлю ТЗ и вышлю вам на почту в ближайшее время!