ggv Anton DemidovИтак, номер один - лёгкость использования - читаем Опускаю легкость использования как сильно субъективную вещь. это не субъективная вещь, это измеряется в человеко-часах и количестве багов в доморощенных методах работы со строками переменной длины. И всё из-за отсутствия родной поддержки в языке программирования. В Оракле я могу сравнить две строки как a < b, а в Коболе придётся структуры стравнивать. Конкатинация строк: a = b || \' blabla.\', в Коболе всё ручками (найти конец использованного буфера строки b; скопировать в продолжение вторую строку; вычислить новую длину строки и сохранить её; везде проверка переполнения)
ggv
Anton Demidov
Номер два: качество имплементации в БД (ладно, ладно, ожидая шквал возмущений от ggv и ко. перефразирую это в "особенности реализации")
Tips for using VARCHAR and VARGRAPHIC data types in databases
Там говорится о том, что VARCHAR это всё равно фиксированный CHAR плюс опциональный сегмент, за который вы заплатите дополнительным i/o
А вот отсюда можно ли по-подробнее.
Так как и фиксированный сегмент может быть 0 размера. И это указано в доке.
Да и вообще бы хотелось аргументированную критику подхода.
По мне, так представленный подход довольно неплохо справляется с задачами, и дока показывает как его использовать наилучшим образом.
Короче - и что не понравилось?
Ну и поскольку вы разработчик, то сразу с анализом в каких случаях это увеличивает I/O и почему нельзя было его улучшить (руководствуясь докой), раз вы уже с этим сталкивались.
Или опять это ваше теоритезирование?
Что мне не понравилось? То что в Оракле у меня всегда один io. В Дб2 это либо 1 io, но перерасход дискового пространства (ALLOCATE > 0, FIXED CHAR de facto), либо 2 io (ALLOCATE = 0 либо ALLOCATE > 0 и строка длиннее этого порога)
ggvКак и с вопросом по долям распределения баз, на который вы так и не ответили? Топик даже открыл по этому поводу, вы просто не заметили. Вот конктретная ссылка на отчет Gartner по 2005 году.

ggv1) опять же - по удобству это сильно субъективно. Фану COBOL кажется одно, а у вас другие глюки.Вы, похоже, себя причисляете к клану людей, которые и финансовые приложения на ассемблере писать будут

ggv2) А вы сами то отчет читали? Мне кажется, что нет.
Потому как даже не поняли, что отчет по вашей ссылке за 2004 год.
Да и указаных вами цифирь в нем нет.
Если, конечно, мы оба сотрели один вариант отчета.
Отчёт 2005 года по результатам 2004 - что тут непонятного? Или просто придратся захотелось? Зачем?
ggv
А про I/O - дык это , как я понял, опять теоретизирования... Любое чтение оригинальной документации - "теоретизирование", или вы предпочитаете сначала стукнутся лбом о проблему, а потом доку читать (теоретизировать в ваших терминах)? Не похоже на вас (судя по вашим постам и кол-ву ссылок на документацию IBM). Но что это тогда - корпоративная солидарность? Опять же - зачем? Показать, что продукт ХХХ - идеален? Такого не бывает, всегда есть какие-либо недочёты, на один из которых я и указал. Причём это проблема принципиального характера и растёт она из ориентации всей системы на обработку строк фиксированной длины.

ggvПогодите - давайте по порядку.
Про цифры из отчета.
Давайте найдем указанные вами 85%
Если это ложь - то разговор закончен.
Если нет - то тогда можно и про I/O, и про удобство, про то, что финансовые приложения как раз на COBOL и писались.
Ну вы право ....