Здравствуйте, koandrew, Вы писали:

K>Что такое "ошибка структуры БД"? По моему разумению, структура БД либо правильная (адекватная задаче), либо нет. Опишите поразвёрнутее, что вы тут имеете в виду — тогда попробую помочь сформулировать фразу на английском.

Есть продукт номер 1. На основе которого через не определенное время выходит независимый продукт номер 2, потом 3,4 Основная концепция БД при этом не меняется она просто дополняется. Но не всегда так как бы хотелось например ранее неиспользуемые поля существовавшие для возможности расширения системы на будущее начинают использоваться совсем в других целях(об этом потом забывают оно висит понижает быстродействие и увеличивает размер), исправить не сложно но это если найдеш. Плюс например немного нагрузив БД оказываеться что при определенной нагрузке уникальный идентификатор через пол года будет совсем не уникальным, в хранимую процедуру включена абсолютно непонятная белиберда которая приводит к сбою, она просто осталася в продукте 4 от продукта 1. И почему все так жутко медленно работает при относительно небольших нагрузках и размерах БД, ну да первоначальный прародитель продукт 1 оставил за собой кучу мусора который в данном ПО уже не нужен.

Вот примерно так а там целый лес дров не все данные заходят, синхронизация не полная, неправильное округление, ни та кодировка при миграции, ни тот тип данных т.е. он работать будет но зачем мне для целого поле типа текст глупо зачем нагружать ЦБД ненужной проверкой вводимых данных, можно конечно фильтровать ввод в клиенте но при интеграции с сторонним ПО что делать там переписать возможности нет.

В общем тот кто писал версию 1 ущел, а дальше как обычно реформаторы на реформировали.
Ну надеюсь смог объяснить.