Как обновляют базы данных при ADO.NET?

Когда допустим была программа версии 1 после обновления её до версии 2 где в базе были изменения(столбцы, таблицы добавлены и удалены)
Что нужно делать? прочитывать в базе каждый столбец таблице и потом запросами удалять, изменять или добавлять? Или же есть что то на подобие Users если что то не совпадает, то заменит само под новый запрос.

Просто даже не знаю как грамотнее сформулировать вопрос чтобы в гугле задать так обновление базы звучит как обновление ПО, а не как советы по обновлению внутренних таблиц-столбцов.

0

миграции для этого существуют

0

Dr9vik, миграция в ADO.NET? и каким SQLм?

0

Сообщение от КВА696 миграция в ADO.NET?

вот и настал момент когда надо Адо Нет сказать нет и подключить EF

0

Сообщение от КВА696 Что нужно делать?

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

Сообщение от Dr9vik вот и настал момент когда надо Адо Нет сказать нет и подключить EF

Внезапно, миграции можно делать очень удобно и быстро БЕЗ EF. EF - ORM в первую очередь. Для миграций есть куда более удобные вещи.

1

Сообщение от Usaga Внезапно, миграции можно делать очень удобно и быстро БЕЗ EF. EF - ORM в первую очередь. Для миграций есть куда более удобные вещи.

конечно есть
только вопрос, зачем? если EF все умеет, и для начала хватит с головой

0

Usaga, Задачи ни какой нету. Просто интересно какие варианты применяют в основном.

Сообщение от Usaga Тут от вас нужно больше подробностей как в базе изменения появились.

Кроме как простого примера что в новой базе нам дапустим нужно поле новое Name а поле Дата не нужно. ну и таблица пусь там добавится или удалится. И все это надо к примеру отдать другому человеку у которого версия 1 программы работает. и чтобы он не занимался экспортом импортом в ручную а просто запустил exe и радовался))

Добавлено через 2 минуты

0

Сообщение от КВА696 на ADO.NET за час на EF я это делаю с матом психами и как повезет))

например?

0

Dr9vik, https://www.cyberforum.ru/ado-... 50548.html
На CORE перешел и вопрос частично был решел потом гемор в написании этих конфигов. EF тот что не core тот меня вообще с командами миграции просто выбесил постоянно какая то ошибка. В общем EF надо время и терпение и желание которых нету.

0

Сообщение от Dr9vik например?

Многоуровневые запросы с оконными функциями, CTE, join на подзапросы внутри которых тоже join по группе критериев. Да любые реальные выборки, кроме CRUD и минимального JOIN, на голом SQL пишутся быстрее (и понятны куда более широкому кругу лиц), чем попытка получить что-то похожее на EF (в т.ч. и по эффективности плана получаемого запроса). Да даже в этой ветке я пару раз заводил темы, где пытались перевести подобные запросы на EF.

Ещё на EF не получится реализовать динамическое изменение набора колонок для проекции. Ну т.е. теоретически это возможно, если генерировать EF-контекст в рантайме, но это уже какое-то сверхшаманство.

А у EF-миграций есть один весомый (для некоторых сценариев) недостаток - они не умеют работать по реальной структуре БД, только по предполагаемой, указанной в метаданных.

Добавлено через 13 минут

Сообщение от КВА696 Что нужно делать?

Вариант - в процессе разработки все нужные SQL-скрипты пишутся вручную и добавляются в план публикации. При публикации релиза, эти SQL выполняются либо вручную с контролем, либо скриптом публикации.

Вариант - пишется/покупается/ищется на гите утилита, которая умеет сравнивать структуру двух БД и строить SQL, устраняющий различия. Т.е. вы в своей девелоп-базе добавили поля/таблицы, поменяли индексы и т.п., потом запустили утилиту, она выдала список различий. Может автоматически применить. Может выгрузить информацию о структуре эталонной БД в JSON, чтобы потом на её основании построить дифф и обновить БД где-то у клиента (не имея доступа к вашей девелоп-базе).

2

kotelok, при втором варианте получается клиент должен последовательно обновления получать вначале версия 1 потом 2 потом 3 или при этом варианте умеет соображать при пропуске к примеру 2 версии?

Если я правильно понял liquibase о котором написал Usaga это второй вариант?

первый вариант тоже чем то похож на 2. А простым перебором разве не пользуются к примеру открыл базу проверил все ли таблици есть после открыл каждую таблицу и выдал имена столбцов и сравнил с полями классов и относительно них добавил или удалил столбец.

Добавлено через 4 минуты
я как то думал что у умного SQL есть запрос волшебный создать таблицу если она есть не создавать (он есть CREATE TABLE IF NOT EXISTS), а если та таблица что существует не соответствует запросу то как то самостоятельно удалить или добавить ненужные столбцы))))

0

Сообщение от КВА696 при втором варианте получается клиент должен последовательно обновления получать вначале версия 1 потом 2 потом 3 или при этом варианте умеет соображать при пропуске к примеру 2 версии?

Нет, это при EF-миграциях клиент должен их последовательно применять. И при этом быть на 100% уверен, что структура/версия базы соответствует метаданным.

Второй вариант - это когда у вас есть целевая структура эталонной базы, и есть структура базы клиента в любом состоянии, в т.ч. в состоянии "ну я тут ручками залез и что-то поломал". Утилита строит диф для доведения базы клиента до эталона. С учётом всех нюансов, с учётом правильного порядка выполнения полученных SQL. Это и есть тот самый "простой перебор". Но на деле он не такой уж и простой оказывается, когда начинаешь это реализовывать. Куча нюансов. И тут вообще никакого понятия версий нет по сути, есть лишь эталон, к которому надо привести клиентскую базу, и какое-то непонятное текущее состояние клиентской базы.

1

kotelok, тобишь это вариант ТЕТ-А-ТЕТ когда с каждым клиентом придется работать индивидуально. А как работают когда клиентов много к примеру браузер опера, надо немного в базе что нить поправить. И у клиентов разные версии кто то подряд кто то через 1-2 обновляется. В таких случаях только первый вариант?

0

Добавлено через 3 минуты

Сообщение от КВА696 kotelok, тобишь это вариант ТЕТ-А-ТЕТ когда с каждым клиентом придется работать индивидуально. А как работают когда клиентов много к примеру браузер опера, надо немного в базе что нить поправить. И у клиентов разные версии кто то подряд кто то через 1-2 обновляется. В таких случаях только первый вариант?

Нет, это именно для массового распространения идеальный вариант, в отличие от EF-миграций.

1. Вы собираете релиз програмы. В этот момент утилита сканирует вашу БД, сохраняет информацию о её полной структуре в JSON. Этот JSON включается в дистрибутив/обновлятор (общий и одинаковый для всех 2000 клиентов).
2. Клиент запускает у себя дистрибутив/обвновлятор программы. В процессе обновления запускается та же самая утилита, которая сканирует БД клиента и выдаёт информацию о её полной структуре в JSON той же структуры.
3. Далее, всё так же в процессе обновления на стороне клиента, утилита сравнивает эталонный JSON из инсталлятора и тот JSON, что получился у конкретно клиента по его базе. Выявляет различия. Строит дифф-SQL. Выполняет дифф-SQL на базе клиента.
4. Итог - независимо от того, в каком состоянии у клиента база была до обновления, после обновления она будет на 100% соответствовать нужной структуре.

1