подходы в разработке БД

← →
Sergey13 © (2002-11-04 09:44) [40]

2Dr_Mike © (02.11.02 01:17)
Мой тебе совет. Решай проблемы по мере их возникновения. С опытом возможно придет способность предугадывать их возникновение. А пока... Ты еще структуру базы не нарисовал, а уже думаешь, что все существующие в мире СУБД тебе узковаты в плечах.

← →
Anatoly Podgoretsky © (2002-11-04 09:56) [41]

Тут явно требуется покупка специалиста для оказания услуг

← →
passm © (2002-11-04 11:02) [42]

Sergey13 © (29.10.02 10:04)> В целом, я понимаю твой критичный подход, ибо пределы есть для всякого продукта. Просто хотелось сказать, что эти пределы для задач широкого круга недостижимы (если не постараться :) ).
> И из того, что DB2 круче dBase это абсолютно не следует.
> Иначе все что можно крутилось бы на IB - тоже кстати клиент/сервер.
СУБД СУБД рознь :)
И есть абсолютная уверенность что и на 10 млн, и на 100 млн скорость работы будет прежняя. В данном случае требуется грамотное администрирование СУБД и распределение/планирование системных ресурсов.
Другой вопрос: а действительно необходимо хранить данные, например, 20-летней давности? Но это уже зависит от заказчика продукта.
DB2 хорошо показала себя при работе с БД в сотни гигабайт, и ограничения касаются не столько размерности таблицы, сколько размерности табличного пространства (tablespace).

← →
Sergey13 © (2002-11-04 11:46) [43]

2passm © (04.11.02 11:02)
>И есть абсолютная уверенность что и на 10 млн, и на 100 млн
>скорость работы будет прежняя.
Вашими бы устами.... Я и не говорю, что будет работать в 10 раз медленнее (тут не линейные зависимости), но в абсолютной уверенности в ОДИНАКОВОЙ скорости я тоже шибко сомневаюсь. Хотя бы потому, что 100млн в 10 раз больше 10млн. По занимаемой памяти например, которую следует лопатить процессору.
Хотя... не хочу и разубеждать. Лень. 8-) Тем паче, что с DB2 не работал и мои рассуждения были чисто теоретического плана.

Sergey13 © (04.11.02 11:46)> Если я правильно помню, то зависимость между объемом таблицы и скоростью работы с ней логарифмическая. След-но чем дальше, тем меньше :)
Я вовсе не хочу сказать, что на объем данных не следует обращать внимания. Заводя разговор на данную тему хотел сказать, что разбиение одной таблицы на несколько, дабы увеличить скорость работы в данном случае нецелесообразно.
Представь, есть журнал документов:
TABLE1 (ID: CHARACTER(13) FOR BIT DATA NOT NULL, DOC_NUM VARCHAR(16)...
И для быстрого доступа к ней документы, например, двухмесячной давности сбрасываются в ее копию.
Вот и хотелось сказать, что расходы на поддержание такого механизма, ИМХО, превосходят расходы на хранение данных в одной таблице. Еще раз скажу, если заказчик хочет хранить ВСЕ свои электронные документы.
Насчет одинаковой скорости - это, конечно, не корректно, но при правильном подходе, пользователь разницы во времени не почувствует (впрочем, это зависит от железа). К тому же есть такие приятные вещи как параллелизм, статистика на индексы...

подходы в разработке БД Найти похожие ветки