Observer

.... .... лучше бы не лезть туда, где вы ничего не понимаете. СО НЕ являтеся ООСУБД. Это ПО. Есть методика разработки, которая является объектно-ориентированный. Есть Объектно(документо-) ориентированные системы хранения. но ПО являться базой данных не может, потому что БД - суть совокупность данных. Понимаете? Бд, это просто стопка книг (классический случай). А СО - пришедший в библиотеку читатель. СУБД - это библиотекарь. ....... На ваш вопрос есть прямой ответ: нет, они не врут. Да, это действительно долго, трудно и муторно. Поэтому они и не хотят брать деньги (кто-то выше упоминал, что предлагал). Потому что ТРУДНО. ......

В БД есть таблица, кажется - Artikles. В ней есть поля. Они являются только зеркалом того, с чем работает ПО. Поля же, которое коррелировало с внутренними структурами, в БД НЕТ. Вносить значение более 20 символов некуда. Если же распаковать in-memory object, и изменить его, то любое школоло, державшее в руках хотя бы Вирта, скажет, что будет невозможность распаковать объект. Ибо с т р у к т у р а. А, в случае ряда языков, еще и фиксированная структура. Конкретно СО выдаст что-нибудь типа "не удается прочесть настройки". Прочтите уже "Алгоритмы и структуры", а? Или погуглите "указатели ссылки чтение и запись памяти". И все же: какой дурак вам вбил в голову, что БД диктует коду, а не код БД? Что вы к несчастному хранилищу, которое ни за что не отвечает, вообще прицепились такой толпой? Это вам Access прошлое нашептывает? Так ведь он был создан, чтобы даже дурак мог им пользоваться, со всеми полагающимися ограничениями, чтобы этот самый дурак себе в ногу не выпалил.

..... Так-так, продолжайте, коллега. Есл ине затруднит, а какую связь вы усматрвиаете между способом хранения и способом обработки? Ен приходило ли вам в голову, что длинна поля в БД - суть отражение длинны типа данных в ПО, а не наоборот?

Привет! ..... ..... СО не использует ничего, что не применимо к ANSI SQL 99. Сейчас 2011 год. Между прочим, "зашифрована" уже позволит любому ...... сделать предположение о неких структурированных данных, что плавно подносит к мысли к адресному чтению. А уж эта простая мысль объясняет, почему "перелопать большую часть программы" внезапно становится суровой реальностью. Теперь второе и правильное: нет, увеличить длинну поля не сводится к "заменить цифру тута". Ровно как добавление неких пользовательских расчетов не сводится к "да шо тут сложнава проста тут вот кнопку дабавить". Да, специфика хранения и обработки данных потребует серьезных изменений в коде, которые придется долго тестировать. Поэтому браться за это вот прямо сейчас нет ресурсов и времени. Будет ли сделано когда-нибудь? Наверняка. Когда? Как появятся ресурсы. Что можно сделать? Ну, например оплатить эти работы? Эй, постойте, куда ж вы все...? КСТ делает, что может. Есть ряд ограничений, в том числе связанных с текущей платформой.