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

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

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

В общем случае - никаких.
Вести разработку строго в одной среде (типа как в 1С) и не использовать всех возможностей СУБД.Пока знаю один. Утоньшение клиента относительно обработки частных данных, например, атрибутов. Если разработать изначально архитектуру клиента, чтобы он опирался на некие "интерфейсы", а не на реализации выборок и изменений данных. Получается прямая противоположность 1С. Правда, здесь другая крайность, если идти до конца по этому пути, то можно переизобрести RDP.


Вопрос не в том, как сделать, чтобы работало в каком-то конкретном случае, а в том, чтобы такая проверка не понадобилась.


Такой вопрос у меня возник очень давно, когда я работал с Delphi 3. Зафетчил колонки в датасеты и любое изменение в базе приходится повторять в клиенте.

Предлагаете тому мне именовать поля на русском, чтобы в гриде всё было понятно пользователям? Или использовать "словари", кажется, что-то такое в BDE было.

Пока вы говорите, что всё неверно, но не говорите в каком направлении двигаться. Подскажите примеры какие-нибудь.

Это выглядит удобненькой и красивенькой организационной мерой, которая подчиняет себе всё. Как она помешает сделать несколько ALTER в базе?

Так я и делал, но вопрос не об этом. Задача в том, чтобы расхождение не могло произойти принципиально(насколько это возможно, конечно), а не как бороться с расхождением. Или, чтобы расхождение было изолировано в базе, т.е. чтобы до клиента это никаким образом не доходило.

В полном виде, возможно, не имеет. Вопрос в том, как, хотя бы, приблизиться к её решению.

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

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


Ещё один вопрос- часто с базы тянутся все поля, даже если у пользователя часть их скрыта. Поскольку .visible колонке выставить проще, чем из запроса исключать поле.