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

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

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

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


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


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

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

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

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

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

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

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

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


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

Кажется, в 1с нельзя было произвольно альтерить таблицы, PK или просто индексы переставлять. Если так, то о чём разговор? Напоминаю, вопрос о том, чтобы клиента отвязать от базы настолько, насколько можно.

Можно ли физически изменить таблицу в БД и не поменять описание формы? Если можно, то как можно узнать, что форма не соответствует таблице? Без привлечения системы контроля версий, конечно.

Скрипты на языке, поддерживаемом базой или поддерживаемом клиентом?

А если поменять в таблице то, что используется в формах? Будет ли ошибка?

В сети где-нибудь лежит?

Были поля f1 int,f2 date,f3 varchar. Стали поля f10 float,f20 time,f3 varchar. В MySQLWorkbench все изменения прописали. Клиент после этого запустится?

Там только видеоинструкция для конфигуратора, документации для программиста не увидел.

Верю вашему опыту, но не оставляю надежды.

Правильно ли я понимаю, что из базы поднимаются все данные через что-то типа


А дальше происходит привязка полей датасета к полям формы, которая просто игнорирует несоответствия и отсутствия?

Что такое метаданные таблицы в вашем понимании? На примере sql сервера можете объяснить? Я просмотрел три pdf документации на вашем сайте- выглядит красиво, но никаких технических особенностей не видно. Я интересуюсь как разработчик, а не как внедренец какой либо готовой системы.

ViPRos,

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

Применяете ли вы логику выборок во view/процедурах или только таблицы?