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

← →
kserg@ukr.net (2002-10-24 18:02) [0]

Привет всем.
Впервые сталкиваюсь с такой развитой задачей, вот и прошу
подскажите подходы в решении след.задачи разработки БД

У меня есть задача автоматизировать обработку инфо в фирме.
Планируется куча таблиц (структура примерная, причем некоторые таблицы «распадаются» на несколько):

- СПРАВОЧНИК ИЗДЕЛИЙ (НОМЕНКЛАТУРА: тип изделия(материал,ПКИ), назва,обозначение,поставщик, условия поставки, цена, тех.хар-ки и тд)

- ПРОЕКТЫ(перечень позиций входящие в состав проекта: название,обозначение, поставщик, кол, цена и тд),

- ПОСТАВЩИКИ (назва, адреса,контакты и тд)

-ЗАЯВКИ(дата заказа, поставщик, название, обозначение, кол, цена, условия поставки/оплаты и тд.)

- СКЛАД(приход/расход): склад, получил от фирмы, название,обознач, кол, выдано на проект, кол и тд)

Даже при первом осмотре видны связи-ссылки.
Это вполне нормальный подход: хранить в таблицах с данными IDссылки на справочники.

Проблема возникает в связи со след.: если использовать в кач-ве ID-коды (т.е. достигается строгое соот-е между master-detail таблицами) то возникает проблемы с вводом данных.
В таких случаях ввод в связанные поля я обычно реализовал как выбор из списков.
Но в списке может содержаться сотни названий…
(попробуй-ка глазками выхватить нужную строку)

Если же в таблицах использовать Look-Up поля, позволяющие либо выбрать из списка-справочника либо ввести ручками, то теряется достоверность вводимых юзером данных :(

Какие кто предлажит решения?

Заранее благодарен.

← →
Val (2002-10-24 18:18) [1]

отдельная форма редактирования(не в гриде) - вызов отдельной формы-справочника.

← →
Delirium (2002-10-24 18:23) [2]

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

← →
{bas} (2002-10-24 18:25) [3]

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

← →
Johnmen (2002-10-24 18:26) [4]

>Delirium © (24.10.02 18:23)
>БД должна удовлетворять требованиям нормализации...

Должна, но не обязана ! :-)))

← →
Delirium (2002-10-24 18:41) [5]

> Johnmen ©

Не углубляясь в теорию нормализации, смею утверждать, что любая современная реляционная (удовлетворяющая 12-и правилам Кодда) БД должна и обязана быть доведена до 3S нормальной формы (Бойса-Кодда) - Ни первичный ключ, ни какая-либо его часть не должны зависеть от не ключевого атрибута.

← →
kserg@ukr.net (2002-10-24 18:57) [6]

Спасибо уважаемым знатокам.

Признаюсь надеялся услышать чё-нибудь попроще и при этом работоспособное решение

:(

← →
Delirium (2002-10-24 19:14) [7]

"...чё-нибудь попроще..." - это не то, чем должен руководствоваться профессионал (или желающий таковым стать) в области БД.

← →
Xenon (2002-10-24 19:44) [8]

ID-коды использовать все-таки придется.
Чтобы выбирать значения используй компонент TRxDBLookupCombo
из библиотеки RxLib. Очень удобно.

← →
[NIKEL] (2002-10-24 19:55) [9]

Определись с понятиями, я делал так
есть такое понятие как ОПЕРАЦИЯ и соответственно таблица операция
у операции есть такие атрибуты как:
тип операции (призод, расход, списание, ввод нач. остатков и т.д.)
id операции
дата начала операции
дата конца операции (и возможно, дата когда операция должна завершиться, напртмер - резервирование товара по счету на опред. время)
id документа операции(документ основание - счет, заказ ...)
id контрагента участвующего в операции
поле to_sklad (на какой склад)
поле from_sklad (со склада)
поле op_can_edit (признак проведенности операции)
и возможно поле с комментарием

также существует таблица (назавем ее invoice) для отрожения данных по операции(т.е. какие товары и в каком количестве и по каой цене участвуют в операции) - поля
invoice_id
op_id (для какой операции данная запись)
goods_id - id товара
g_count - количество
price - за ед. товара
unit_id - id ед. измерения для товара

так вот когда свершается операция то в табл. operations добовляется запись с нужными значениями - и для этой операции заполняется табл. invoice
Также есть таблицы справочники, агенты, счета, банки, ГТД, группы товаров, товары, цены для товара, ед. измерения для товаров, договора, склады и т.д.

на самом деле я писал большую систему где много разных нюансов

Может скоро напишу статью, о том как я писал базу данных для магазина Автомобил. Запчасти и Клиента к ней :)

← →
MsGuns (2002-10-24 20:02) [10]

Справочники - это, конечно, проблема (вернее, проблема создания их интерфейса), но главные проблемы в этом проекте - совсем не они ! Я понял, что надо держать состав изделий и ПКИ к ним. Вот это и естьГЛАВНАЯ проблема, т.к. там может быть древо, да еще какое ветвистое 8). И с заявками тоже будут траблы те еще. Особенно если учитывать комплекты.

А на счет справочников - ИМХО, Val © (24.10.02 18:18)
дал дельный совет. И НИКАКИХ КОМБОБОКСОВ на БОЛЬШИЕ или многоколоночные справочники. В гриде с такими справочниками не работа, а мУка. Пока найдешь что надо, кинешь все на фиг. Первые буквы не походят, т.к. искать надо не по ключевому полю, а по одному из сопутствующих (причем иногда по одному - наименование, а иногда по другому - цена, а может быть еще по третьему, четвертому и т.д.). А на форму (справочник в гриде) можно положить фильтр, переупорядочить по любой колонке, использовать куда более мощные, чем в комбобоксе, средства поиска. Я уже не говорю о возможности тут же добавить в спр-к новую запись.
Но, повторюсь, это для СЛОЖНЫХ СПРАВОЧНИКОВ:
- больших по кол-ву записей
- имеющих большое кол-во сопутствующих полей
- состоящих их более чем одной таблицы (например, справочник бух.операций и сложных проводок к ним)
- требующих добавление (не удаление и не правку) "на лету"

← →
Sergey13 (2002-10-25 10:05) [11]

2Delirium © (24.10.02 18:41)
>.. любая современная реляционная БД должна и обязана быть доведена до 3S нормальной формы
Позволю себе не согласиться. ИМХО прав Johnmen ©. Нормализация не догма и не цель, а только метод позволяющий избежать избыточности данных. Придумывалась эта штука во времена когда мегабайт памяти стоил лимон баксов. С тех пор мир сильно изменился. И для улучшения производительности (например) можно применять и ДЕнормализацию(то же кстати метод описанный в литературе).

← →
kserg@ukr.net (2002-10-25 10:17) [12]

Спасибо >[NIKEL] ©
и >MsGuns © (24.10.02 20:02)
очень точно описал суть задачи - сразу вижу, что сталкивался с подобным. Действительно, ко всему прочему наварачивается задача входимости(построение дерева), но от данной задачи я пока отказался.
Если рассмотреть источник проблем в решении данной задачи - это поиск компромиса между требованиями достоверности данных(ведение кучи справочников), простотой ввода и теми сроками, котр. мне ставят на выполнение данной задачи...

← →
Delirium (2002-10-25 13:55) [13]

> Sergey13 ©
Я не возвожу нормализацию в неукоснительную и, по большому счёту, абстрактную догму. Разумеется идеально нормализованых БД в природе не существует, а если бы и были - работа с ними превратилась бы в большую проблему, чем обеспечение целостности, формализации, экономии ресурсов и других нрмальных достоинств. Я ведь указал на необходимую и достаточную степень нормализации, так как далнейшие ухищрения - тема для диссертаций, а не для практической работы. В общем, я считаю, что степень нормализации должна закладываться при логическом проектировании БД и в дальнейшем не понижаться, это конечно IMHO ;)

← →
Johnmen (2002-10-25 14:09) [14]

>MsGuns © (24.10.02 20:02)

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

>Delirium © (25.10.02 13:55)
>В общем, я считаю, что степень нормализации должна
>закладываться при логическом проектировании БД и в дальнейшем
>не понижаться, ...

Твоими устами, да мед пить !
А вот в реальности иногда приходится и понижать (по мере возрастания аппетитов заказчика)....

← →
MsGuns (2002-10-25 14:15) [15]

>Delirium © (25.10.02 13:55)

Боюсь опять навлечь на себя гнев монстров БД, но заявлю категорично.
Задача построения графов (а состав изделий - это как раз из этой серии) на БД с НЕИЕРАРХИЧЕСКОЙ структурой ФИЗИЧЕСКОГО хранения информации - является нормализуемой лишь частично ! Можно нормализовать узлы (т.е.детали, сборки и т.д.), но никак не СВЯЗИ МЕЖДУ НИМИ. Хотя бы потому, что они носят весьма временный характер из-за большого кол-ва конструкторско-технологических изменений. Также ИМХО

← →
Alex Chu (2002-10-25 14:21) [16]

Если говорить о принципах проектирвоания БД, то говорить больше приходится о качестве ТЗ и Грамотности (образования и опыта) Постановщика задачи.

Но у нас в стране, зачастую, задачи ставят люди, мало разбирающиеся в аспектах Программирования и Структур БД в частности.

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

Какая, б.., нормализация в этот период?!!

← →
Ops (2002-10-25 14:29) [17]

В справочниках введи код - видимый(удобный) для человека. И пусть человек вводит код в поле а не осмысленное значение. И скорее всего эти коды уже есть. К примеру бугалтера помнят на вскидку более 100 кодом основных для заполнения их в бумажках...
А если он не помнит кода в справочнике пусть уж озадачится полноценным поиском в отсортированном списке...
Такую задачу мне поставили на производстве - для нормоконтрлеров.. А коды они распечатывали и вешали рядышком на рабочем месте.

← →
Johnmen (2002-10-25 14:35) [18]

>Alex Chu (25.10.02 14:21)

Абсолютно точное замечание !!!

>...задачи ставят люди, мало разбирающиеся ...

Зачастую, просто НЕразбирающиеся !!! И не могущие в принципе формализовать задачу...

← →
MsGuns (2002-10-25 14:41) [19]

Так в чем проблема ? Берите постановку сами ! Нормальные огурцы так и делают. А от заказчика (клиента) нужны только ИСХОДНЫЕ ТРЕБОВАНИЯ. Нормально сработанное ТЗ - как min 50% всего объема работы.

← →
Alex Chu (2002-10-25 14:45) [20]

Теперь можно всем пожать лапки!

Без полноценного ТЗ даже начинать работу НЕЛЬЗЯ!
И поверте, MsGuns ©, это далеко не 50%...это БОЛЬШЕ!

Кодеров сейчас тучи, а программеров и Постановщиков мало!

← →
MsGuns (2002-10-25 14:58) [21]

>Johnmen © (25.10.02 14:09)
>MsGuns © (24.10.02 20:02)

>По поводу использ.формы редактирования вместо грида - согласен,
>но аргументы, тобой приводимые, весьма слабы, а некоторые просто некорректны...

Ну, с аргументами у меня вообще сплошные траблы (ЁМХО)
Особенно если их не утружаются не то что аргументированно
опровергнуть, но даже прочитать и постараться понять.

← →
Delirium (2002-10-25 15:10) [22]

> Johnmen ©

"А вот в реальности иногда приходится и понижать" - Согласен, иногда приходится (к сожалению), однако это уже больше творчество чем наука - предугадывать возможные расширения и строить проект в соответствии с ними. Возвращаясь к автору ветки, дам ещё несколько советов, возможно пересекающихся с пердыдущими ораторами. Необходимо чётко разделять по структуре и по нотации следующие объекты БД:
1) Справочники (идентификатор, значение)
2) Связи (cross table) (идентификатор_справочника_1, идентификатор_справочника_2) - лучше создавать отдельный кросс для каждой пары спавочников
3) Документы (master->detail) - лучше не создавать более чем двух-уровневые документы
4) Агрегаты (вычисления по документам) - следует увязать на триггерах, дабы ускорить рассчёты на больших таблицах
5) Истроии (точные копии вышеозначенных таблиц с дополнительным ключом)
Думается, если придерживатья такой методики, получить высоко-нормальную базу не проблема, даже на очень сложных проектах.

← →
MsGuns (2002-10-25 15:17) [23]

>Delirium © (25.10.02 15:10)

Я бы еще добавил
6)Права - определяют диапазон функций (прав) специализированных клиентов (т.е. директору-директорово, бухгалтеру-бухгалтерово) и прав к доступу к данным

← →
passm (2002-10-25 15:26) [24]

Delirium © (25.10.02 15:10)> 5-й пункт для клиент/сервер не обязателен. Фильтры спасут от перегрузок :)

← →
Johnmen (2002-10-25 15:33) [25]

>MsGuns © (25.10.02 14:58)
>Особенно если их не утружаются не то что аргументированно
>опровергнуть, но даже прочитать и постараться понять.

Не надо гнать волну...:)
"Вы хочите песен ? Их есть у меня" (арг-ты)

>В гриде с такими справочниками не работа, а мУка.
>Пока найдешь что надо, кинешь все на фиг.

Никаких проблем с поиском. (некорректный)

>Первые буквы не походят, т.к. искать надо не по ключевому полю,
>а по одному из сопутствующих (причем иногда по одному -
>наименование, а иногда по другому - цена, а может быть еще по
>третьему, четвертому и т.д.).

И в чем проблема-то ? (некорректный)

>А на форму (справочник в гриде) можно положить фильтр,
>переупорядочить по любой колонке, использовать куда более >мощные, чем в комбобоксе, средства поиска.

Это все можно сделать и при корр-ке в гриде. (слабый)

>Я уже не говорю о возможности тут же добавить в спр-к новую
>запись.

Никаких проблем при работе с гридом. (слабый)

Я, конечно, понимаю, что это не совсем аргументы, но разжевывание реализации приведенных фич есть спам для ветки...

← →
Delirium (2002-10-25 15:33) [26]

> MsGuns ©

Хм, на мой взгляд, разделение прав это скорее проблема приложений, а не БД. Хотя, если иерархия прав и запретов витеевата то, разумеется, такую структуру следует включить в БД и распространить на остальные объекты.

← →
Delirium (2002-10-25 15:38) [27]

> passm ©

"5-й пункт для клиент/сервер не обязателен. Фильтры спасут от перегрузок" - Не ясно о каких перегрузках идёт речь. Истории нужны для аудита документа оборота и справочников, для частичного или полного атката не транзакций БД, а бизнес-операций.

← →
passm (2002-10-25 16:29) [28]

Delirium © (25.10.02 15:33)> На сервере и приятнее и надежней.
Delirium © (25.10.02 15:38)> Согласен. Просто под историей бывает понимают ведение других таблиц с журналом операций. Сброс туда документов такой-то давности... От меня как-то требовали такую реализацию - еле отмахался. Удалось убедить, что в клиент/сервере при хорошей СУБД это не оправдано.

← →
Sergey13 (2002-10-28 10:06) [29]

2passm © (25.10.02 16:29)
>Сброс туда документов такой-то давности... От меня как-то >требовали такую реализацию - еле отмахался.
А че - лень было делать? По моему нормальное требование.
>Удалось убедить, что в клиент/сервере при хорошей СУБД это не >оправдано.
Ну раз клиент/сервер то на него и вешать все что угодно можно? Типа пусть лошадь думает - у нее голова большая. Зачем хранить в основной рабочей таблице накладные пятилетней давности? Смысл то в чем? При таком подходе все равно рано или поздно возникнет большая проблема с производительностью - рост объема данных к этому приведет.

← →
passm (2002-10-28 13:07) [30]

Sergey13 © (28.10.02 10:06)> Лень, конечно. В данном случае такой подход - это, ИМХО, "горе от ума". Делать реализацию архива с выгрузкой в отдельную таблицу (для DB2 еще желательно и TABLESPACE - для "полного удовлетворения" :) ) и механизмы прозрачного доступа к архивным данным только для того, чтобы все лежало по "разным полочкам" ИМХО нецелесообразно. К тому же роста производительности при этом ожидать не приходится, а скорее наоборот. (Запросил пользователь данные с начала года по теперешний момент и делай UNION с сортировкой и с проверкой фильтров уже на двух таблицах... ты уверен, что СУБД подхватит индексы для сортировки? Я - нет.)
Хорошо спланированные данные и индексы позволяют работать быстро вне зависимости от объемов (для DB2 проверено, да и для остальных "серьезных" СУБД также). Есть у меня сейчас таблица почти в 2 млн. строк и все равно "летает" :)

← →
Delirium (2002-10-28 14:03) [31]

> passm ©

Ну, на самом деле, 2 млн. записей это не так уж много. Мне зачастую приходится строить агрегирующие запросы по таблицам до 10 млн. записей. Могу сказать, что при таких объёмах, даже мощные сервера не обеспечивают должную интерактивность данных. По этому пункт (4) (Delirium © (25.10.02 15:10)) бывает весьма эффективен. Есть ещё один подход - промежуточная агрегация, например: на одном из наших складов в день оформляется около 200 заказов, на каждый заказ формируется в среднем 50 накладных, итого 10000 документов в день. Разумеется, с течением времени, объём данных вырастает чрезвычайно. Делаем так - по истечение срока X накладные агрегируются по дням, т.е. попросту 10000 документов сливается в один, так как номенклатура повторяется, экономия в сотни раз, а в год выходит всего-то около 350 документов. При этом агрегаты с интервалом в день не теряют своей актуальности.

← →
passm (2002-10-28 14:25) [32]

Delirium © (28.10.02 14:03)> Это уже отдельная тема :)
Насчет агрегатных данных поступаю почти так же, дабы избежать вычислений на больших объемах (здесь решающую роль играет не столько СУБД, сколько железо). Для этого создаются всевозможные сводные таблицы, которые корректируются со всевозможной периодичностью (зависит от конкретной задачи). Что-то изменяется на лету, а для чего-то вводим понятия "рабочий день", "отчетный период"... А насчет формирования около 350 документов в год - это зависит от заказчика ПО.

← →
Sergey13 (2002-10-29 10:04) [33]

2passm © (28.10.02 13:07)
>"Запросил пользователь данные с начала года по теперешний момент "
Так никто и не говорит, что архивировать нужно помесячно. А вот по годам это уже имеет смысл, если конечно каждый день не проводятся запросы типа "Запросил пользователь данные с начала прошлого века по теперешний момент ".
Тут все дело, ИМХО, что объем инфы с ростом иногда меняет даже планы выполнения запросов, не говоря уже о том, что все равно серваку объективно труднее перемолоть 5 млн нежели 2 млн. Типа на 2млн летало, а на 3 тормоза. При архивировании можно с большой вероятностью спрогнозировать максимальный объем данных и соответственно настроить запросы и индексы.

> Хорошо спланированные данные и индексы позволяют работать >быстро вне зависимости от объемов
Сильно сказано. Но неверно 8-). И из того, что DB2 круче dBase это абсолютно не следует. Иначе все что можно крутилось бы на IB - тоже кстати клиент/сервер.
> (для DB2 проверено, да и для >остальных "серьезных" СУБД также). Есть у меня сейчас таблица >почти в 2 млн. строк и все равно "летает" :)
Проверено на 2 млн. А на 5 проверяли? Или на 10? Я так думаю, что если есть 2 то и 10 кажутся вполне возможными и скоро достижимыми.

Я не утверждаю, что делать это (архивирование) обязательно надо(тут нужно смотреть конкретно по условиям), но говорить что клиент/сервер решает это автоматически эффективно я бы не стал. Собственно о чем я и писал.

← →
Dr_Mike (2002-11-01 01:41) [34]

Кстати, может вопрос не совсем по теме топика, но хочу спросить - если заранее известно, что база данных распределенного сетевого проєкта будет иметь огромное количество составляющих - то не стоит ли попытаться ее разделить на несколько частей (тем более, что часть информации будет храниться не непосредственно в базе, а в связанной с ней файловой структуре), и какими должны быть критериии оценки необходимости такого разделения ?
Просто впервые столкнулся с необходимостью разработки столь масштабного проекта, и пока что даже не могу представить, что меня ждет при его завершении :((

← →
Sergey13 (2002-11-01 11:35) [35]

2Dr_Mike © (01.11.02 01:41)
>... если заранее известно, что база данных распределенного
>сетевого проєкта
Что ты понимаешь под "распределенным сетевым проєктом" -большая локалка или удаленные филиалы на модемах? Что за проект?

> будет иметь огромное количество составляющих
Что за составляющие? Данные для разных задач которые должны перекликаться между собой(типа бухгалтерия - производство) или вообще НЕСВЯЗАНЫЕ между собой наборы таблиц(типа в огороде бузина а в Киеве дядька)?

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

>впервые столкнулся с необходимостью разработки столь
>масштабного проекта, и пока что даже не могу представить, что
>меня ждет при его завершении :((
23 года и другое образование (из анкеты)....
Похоже вам, прежде всего, специалист(ы) нужен. Иначе вы этот проект не завершите никогда.

← →
Delirium (2002-11-01 11:58) [36]

> Dr_Mike ©

Согласен с Sergey13 © , слишком неопределённая задача. Давай более конкретные условия - поможем всем миром (форумом) :)

← →
Dr_Mike (2002-11-02 01:17) [37]

>Sergey13 © (01.11.02 11:35)

Что касается первых трех вопросов, то позвольте на них не отвечать, так как к сказанному добавлять что-то не имеет смысла, тем более что к основному предмету они никакого отношения не имеют.

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

Предполагаемые СУБД по определенным причинам - только с открытым кодом (например тот же IB/Firebird).

Буду благодарен за ссылки на материалы по данной теме.

← →
EternalWonderer (2002-11-02 12:23) [38]

Извините, что вмешиваюсь, но по-моему, "думать о вынесении части из них в отдельную базу на другой сервер" надо в первую очередь не при оценке объёмов (т.е.количества и размера таблиц), а при оценке активности работы с конкретными таблицами, поскольку в наше время серверАм не хватает в основном не дискового пространства, а быстродействия при обработке запросов от большого числа пользователей.
Упрощая, перефразирую: даже если имеются всего две "малосвязанные" таблицы, но 100 000 пользователей, таблицы, возможно, придётся разнести по разным физическим машинам.

← →
MsGuns (2002-11-02 18:18) [39]

>Dr_Mike © (02.11.02 01:17)

Круто вопрос замешан ! Типа я тут буду делать трепанацию черепа, а вы мне по телефону подскажите какими инструментами пользоваться и что резать или сшивать. Или дайте какую-нибудь статеечку 8)))))

← →
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 не работал и мои рассуждения были чисто теоретического плана.

← →
passm (2002-11-04 12:23) [44]

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

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