Гаджимурадов Рустам,

а что там я неправильно сказал?

ГР: Как будто про EB+ES ты всё правильно сказал
kdv: а что там я неправильно сказал?
ГР: Да всё, практически.

просто прекрасно. При этом ты сам пронес ахинею, особенно про "типа не сходится - сразу в сад". Потому что он с самого начала писал про diff.

Гаджимурадов Рустам,

согласись, что алгоритмически все должно быть примерно одинаково, что через клиента, что через ES. Но ES гораздо сложнее пишется. Особенно я не вижу смысла в ES при сравнении метаданных.
Так что вполне можно вначале сделать обычного клиента, а потом, при желании - на ES. Мне даже интересно, существует-ли уже у кого то подобное решение.

Гаджимурадов РустамНе совсем. На сервере есть ещё SQL, в т.ч. множественный,
на клиенте же только построчное сравнение.
for select/for execute statement тоже построчный.
while not Q.Eof
do
Q.Next
то же самое. А join из двух баз сделать нельзя. Так что в ES будут те же циклы. А значит алгоритмически решение будет мало отличаться. Ну и, на клиенте запрос для поиска идентичной записи конструировать тоже проще (я про where).

Гаджимурадов РустамТы всерьёз не понимаешь, что это во-первых, мартышкин труд
двойная работа, а во-вторых, тащить (повторяю) все записи обех БД
на клиента не лучшая идея при наличии альтернатив?
Например, я вижу функционал ChangeManager. Он вообще на Java написан. Понятно что ES он использовать не будет.
Допустим, ES альтернатива, но автор-то "не разобрался". Если идеи нет, в ES тоже фигня получится.

Гаджимурадов Рустамkdv> Особенно я не вижу смысла в ES при сравнении метаданных.
Я бы сказал, что никакой разницы нет. Совсем никакой.
есть, потому что в отличие от данных метаданные разбросаны по разным таблицам. Тупо сравнивать rdb$fields не пройдет.

Впрочем, не вижу тут предмета для спора, это всего лишь варианты реализации. Например, если у автора базы небольшие, я бы с ES связываться не стал, т.к. выигрыш вряд ли будет серьезно значимым.

Гаджимурадов РустамУ Хвастунова и Лободы? :)
я про сравнение данных и метаданных через ES.