| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
подходы в разработке БД
kserg@ukr.net © (2002-10-24 18:02:00)Привет всем.
Впервые сталкиваюсь с такой развитой задачей, вот и прошу
подскажите подходы в решении след.задачи разработки БД
У меня есть задача автоматизировать обработку инфо в фирме.
Планируется куча таблиц (структура примерная, причем некоторые таблицы «распадаются» на несколько):
- СПРАВОЧНИК ИЗДЕЛИЙ (НОМЕНКЛАТУРА: тип изделия(материал,ПКИ), назва,обозначение,поставщик, условия поставки, цена, тех.хар-ки и тд)
- ПРОЕКТЫ(перечень позиций входящие в состав проекта: название,обозначение, поставщик, кол, цена и тд),
- ПОСТАВЩИКИ (назва, адреса,контакты и тд)
-ЗАЯВКИ(дата заказа, поставщик, название, обозначение, кол, цена, условия поставки/оплаты и тд.)
- СКЛАД(приход/расход): склад, получил от фирмы, название,обознач, кол, выдано на проект, кол и тд)
Даже при первом осмотре видны связи-ссылки.
Это вполне нормальный подход: хранить в таблицах с данными IDссылки на справочники.
Проблема возникает в связи со след.: если использовать в кач-ве ID-коды (т.е. достигается строгое соот-е между master-detail таблицами) то возникает проблемы с вводом данных.
В таких случаях ввод в связанные поля я обычно реализовал как выбор из списков.
Но в списке может содержаться сотни названий…
(попробуй-ка глазками выхватить нужную строку)
Если же в таблицах использовать Look-Up поля, позволяющие либо выбрать из списка-справочника либо ввести ручками, то теряется достоверность вводимых юзером данных :(
Какие кто предлажит решения?
Заранее благодарен.
passm (2002-11-04 12:23:00) [1]Sergey13 © (04.11.02 11:46)> Если я правильно помню, то зависимость между объемом таблицы и скоростью работы с ней логарифмическая. След-но чем дальше, тем меньше :)
Я вовсе не хочу сказать, что на объем данных не следует обращать внимания. Заводя разговор на данную тему хотел сказать, что разбиение одной таблицы на несколько, дабы увеличить скорость работы в данном случае нецелесообразно.
Представь, есть журнал документов:
TABLE1 (ID: CHARACTER(13) FOR BIT DATA NOT NULL, DOC_NUM VARCHAR(16)...
И для быстрого доступа к ней документы, например, двухмесячной давности сбрасываются в ее копию.
Вот и хотелось сказать, что расходы на поддержание такого механизма, ИМХО, превосходят расходы на хранение данных в одной таблице. Еще раз скажу, если заказчик хочет хранить ВСЕ свои электронные документы.
Насчет одинаковой скорости - это, конечно, не корректно, но при правильном подходе, пользователь разницы во времени не почувствует (впрочем, это зависит от железа). К тому же есть такие приятные вещи как параллелизм, статистика на индексы...
Sergey13 (2002-11-04 11:46:00) [2]2passm © (04.11.02 11:02)
>И есть абсолютная уверенность что и на 10 млн, и на 100 млн
>скорость работы будет прежняя.
Вашими бы устами.... Я и не говорю, что будет работать в 10 раз медленнее (тут не линейные зависимости), но в абсолютной уверенности в ОДИНАКОВОЙ скорости я тоже шибко сомневаюсь. Хотя бы потому, что 100млн в 10 раз больше 10млн. По занимаемой памяти например, которую следует лопатить процессору.
Хотя... не хочу и разубеждать. Лень. 8-) Тем паче, что с DB2 не работал и мои рассуждения были чисто теоретического плана.
passm (2002-11-04 11:02:00) [3]Sergey13 © (29.10.02 10:04)> В целом, я понимаю твой критичный подход, ибо пределы есть для всякого продукта. Просто хотелось сказать, что эти пределы для задач широкого круга недостижимы (если не постараться :) ).
> И из того, что DB2 круче dBase это абсолютно не следует.
> Иначе все что можно крутилось бы на IB - тоже кстати клиент/сервер.
СУБД СУБД рознь :)
И есть абсолютная уверенность что и на 10 млн, и на 100 млн скорость работы будет прежняя. В данном случае требуется грамотное администрирование СУБД и распределение/планирование системных ресурсов.
Другой вопрос: а действительно необходимо хранить данные, например, 20-летней давности? Но это уже зависит от заказчика продукта.
DB2 хорошо показала себя при работе с БД в сотни гигабайт, и ограничения касаются не столько размерности таблицы, сколько размерности табличного пространства (tablespace).
Anatoly Podgoretsky (2002-11-04 09:56:00) [4]Тут явно требуется покупка специалиста для оказания услуг
Sergey13 (2002-11-04 09:44:00) [5]2Dr_Mike © (02.11.02 01:17)
Мой тебе совет. Решай проблемы по мере их возникновения. С опытом возможно придет способность предугадывать их возникновение. А пока... Ты еще структуру базы не нарисовал, а уже думаешь, что все существующие в мире СУБД тебе узковаты в плечах.
MsGuns (2002-11-02 18:18:00) [6]>Dr_Mike © (02.11.02 01:17)
Круто вопрос замешан ! Типа я тут буду делать трепанацию черепа, а вы мне по телефону подскажите какими инструментами пользоваться и что резать или сшивать. Или дайте какую-нибудь статеечку 8)))))
EternalWonderer (2002-11-02 12:23:00) [7]Извините, что вмешиваюсь, но по-моему, "думать о вынесении части из них в отдельную базу на другой сервер" надо в первую очередь не при оценке объёмов (т.е.количества и размера таблиц), а при оценке активности работы с конкретными таблицами, поскольку в наше время серверАм не хватает в основном не дискового пространства, а быстродействия при обработке запросов от большого числа пользователей.
Упрощая, перефразирую: даже если имеются всего две "малосвязанные" таблицы, но 100 000 пользователей, таблицы, возможно, придётся разнести по разным физическим машинам.
Dr_Mike (2002-11-02 01:17:00) [8]>Sergey13 © (01.11.02 11:35)
Что касается первых трех вопросов, то позвольте на них не отвечать, так как к сказанному добавлять что-то не имеет смысла, тем более что к основному предмету они никакого отношения не имеют.
А теперь насчет того, что же меня все таки интересовало - при превышении какого количества структур и сложности взаимосвязей между ними стоит попытаться вычленить решения для отдельных предметных областей ?
Причем конкретные условия ставить бессмысленно - меня интересует именно теория, так сказать, аналога нормализации-денормализации, но только оперирующего уже не таблицами, а целыми базами,
(упрощая, перефразирую, например, до такого варианта - при каком количестве таблиц стоит подумать о вынесении части из них в отдельную базу на другой сервер?).
Предполагаемые СУБД по определенным причинам - только с открытым кодом (например тот же IB/Firebird).
Буду благодарен за ссылки на материалы по данной теме.
Delirium (2002-11-01 11:58:00) [9]> Dr_Mike ©
Согласен с Sergey13 © , слишком неопределённая задача. Давай более конкретные условия - поможем всем миром (форумом) :)
Sergey13 (2002-11-01 11:35:00) [10]2Dr_Mike © (01.11.02 01:41)
>... если заранее известно, что база данных распределенного
>сетевого проєкта
Что ты понимаешь под "распределенным сетевым проєктом" -большая локалка или удаленные филиалы на модемах? Что за проект?
> будет иметь огромное количество составляющих
Что за составляющие? Данные для разных задач которые должны перекликаться между собой(типа бухгалтерия - производство) или вообще НЕСВЯЗАНЫЕ между собой наборы таблиц(типа в огороде бузина а в Киеве дядька)?
>часть информации будет храниться не непосредственно в базе, а в
>связанной с ней файловой структуре.
Это когда в базе хранятся ссылки на файлы?
>впервые столкнулся с необходимостью разработки столь
>масштабного проекта, и пока что даже не могу представить, что
>меня ждет при его завершении :((
23 года и другоеобразование (из анкеты)....
Похоже вам, прежде всего, специалист(ы) нужен. Иначе вы этот проект не завершите никогда.
Dr_Mike (2002-11-01 01:41:00) [11]Кстати, может вопрос не совсем по теме топика, но хочу спросить - если заранее известно, что база данных распределенного сетевого проєкта будет иметь огромное количество составляющих - то не стоит ли попытаться ее разделить на несколько частей (тем более, что часть информации будет храниться не непосредственно в базе, а в связанной с ней файловой структуре), и какими должны быть критериии оценки необходимости такого разделения ?
Просто впервые столкнулся с необходимостью разработки столь масштабного проекта, и пока что даже не могу представить, что меня ждет при его завершении :((
Sergey13 (2002-10-29 10:04:00) [12]2passm © (28.10.02 13:07)
>"Запросил пользователь данные с начала года по теперешний момент "
Так никто и не говорит, что архивировать нужно помесячно. А вот по годам это уже имеет смысл, если конечно каждый день не проводятся запросы типа "Запросил пользователь данные с начала прошлого века по теперешний момент ".
Тут все дело, ИМХО, что объем инфы с ростом иногда меняет даже планы выполнения запросов, не говоря уже о том, что все равно серваку объективнотруднее перемолоть 5 млн нежели 2 млн. Типа на 2млн летало, а на 3 тормоза. При архивировании можно с большой вероятностью спрогнозировать максимальный объем данных и соответственно настроить запросы и индексы.
> Хорошо спланированные данные и индексы позволяют работать >быстро вне зависимости от объемов
Сильно сказано. Но неверно 8-). И из того, что DB2 круче dBase это абсолютно не следует. Иначе все что можно крутилось бы на IB - тоже кстати клиент/сервер.
> (для DB2 проверено, да и для >остальных "серьезных" СУБД также). Есть у меня сейчас таблица >почти в 2 млн. строк и все равно "летает" :)
Проверено на 2 млн. А на 5 проверяли? Или на 10? Я так думаю, что если есть 2 то и 10 кажутся вполне возможными и скоро достижимыми.
Я не утверждаю, что делать это (архивирование) обязательно надо(тут нужно смотреть конкретно по условиям), но говорить что клиент/сервер решает это автоматически эффективноя бы не стал. Собственно о чем я и писал.
passm (2002-10-28 14:25:00) [13]Delirium © (28.10.02 14:03)> Это уже отдельная тема :)
Насчет агрегатных данных поступаю почти так же, дабы избежать вычислений на больших объемах (здесь решающую роль играет не столько СУБД, сколько железо). Для этого создаются всевозможные сводные таблицы, которые корректируются со всевозможной периодичностью (зависит от конкретной задачи). Что-то изменяется на лету, а для чего-то вводим понятия "рабочий день", "отчетный период"... А насчет формирования около 350 документов в год - это зависит от заказчика ПО.
Delirium (2002-10-28 14:03:00) [14]> passm ©
Ну, на самом деле, 2 млн. записей это не так уж много. Мне зачастую приходится строить агрегирующие запросы по таблицам до 10 млн. записей. Могу сказать, что при таких объёмах, даже мощные сервера не обеспечивают должную интерактивность данных. По этому пункт (4) (Delirium © (25.10.02 15:10)) бывает весьма эффективен. Есть ещё один подход - промежуточная агрегация, например: на одном из наших складов в день оформляется около 200 заказов, на каждый заказ формируется в среднем 50 накладных, итого 10000 документов в день. Разумеется, с течением времени, объём данных вырастает чрезвычайно. Делаем так - по истечение срока X накладные агрегируются по дням, т.е. попросту 10000 документов сливается в один, так как номенклатура повторяется, экономия в сотни раз, а в год выходит всего-то около 350 документов. При этом агрегаты с интервалом в день не теряют своей актуальности.
passm (2002-10-28 13:07:00) [15]Sergey13 © (28.10.02 10:06)> Лень, конечно. В данном случае такой подход - это, ИМХО, "горе от ума". Делать реализацию архива с выгрузкой в отдельную таблицу (для DB2 еще желательно и TABLESPACE - для "полного удовлетворения" :) ) и механизмы прозрачного доступа к архивным данным только для того, чтобы все лежало по "разным полочкам" ИМХО нецелесообразно. К тому же роста производительности при этом ожидать не приходится, а скорее наоборот. (Запросил пользователь данные с начала года по теперешний момент и делай UNION с сортировкой и с проверкой фильтров уже на двух таблицах... ты уверен, что СУБД подхватит индексы для сортировки? Я - нет.)
Хорошо спланированные данные и индексы позволяют работать быстро вне зависимости от объемов (для DB2 проверено, да и для остальных "серьезных" СУБД также). Есть у меня сейчас таблица почти в 2 млн. строк и все равно "летает" :)
Sergey13 (2002-10-28 10:06:00) [16]2passm © (25.10.02 16:29)
>Сброс туда документов такой-то давности... От меня как-то >требовали такую реализацию - еле отмахался.
А че - лень было делать? По моему нормальное требование.
>Удалось убедить, что в клиент/сервере при хорошей СУБД это не >оправдано.
Ну раз клиент/сервер то на него и вешать все что угодно можно? Типа пусть лошадь думает - у нее голова большая. Зачем хранить в основной рабочей таблице накладные пятилетней давности? Смысл то в чем? При таком подходе все равно рано или поздно возникнет большая проблема с производительностью - рост объема данных к этому приведет.
passm (2002-10-25 16:29:00) [17]Delirium © (25.10.02 15:33)> На сервере и приятнее и надежней.
Delirium © (25.10.02 15:38)> Согласен. Просто под историей бывает понимают ведение других таблиц с журналом операций. Сброс туда документов такой-то давности... От меня как-то требовали такую реализацию - еле отмахался. Удалось убедить, что в клиент/сервере при хорошей СУБД это не оправдано.
Delirium (2002-10-25 15:38:00) [18]> passm ©
"5-й пункт для клиент/сервер не обязателен. Фильтры спасут от перегрузок" - Не ясно о каких перегрузках идёт речь. Истории нужны для аудита документа оборота и справочников, для частичного или полного атката не транзакций БД, а бизнес-операций.
Delirium (2002-10-25 15:33:00) [19]> MsGuns ©
Хм, на мой взгляд, разделение прав это скорее проблема приложений, а не БД. Хотя, если иерархия прав и запретов витеевата то, разумеется, такую структуру следует включить в БД и распространить на остальные объекты.
Johnmen (2002-10-25 15:33:00) [20]>MsGuns © (25.10.02 14:58)
>Особенно если их не утружаются не то что аргументированно
>опровергнуть, но даже прочитать и постараться понять.
Не надо гнать волну...:)
"Вы хочите песен ? Их есть у меня" (арг-ты)
>В гриде с такими справочниками не работа, а мУка.
>Пока найдешь что надо, кинешь все на фиг.
Никаких проблем с поиском. (некорректный)
>Первые буквы не походят, т.к. искать надо не по ключевому полю,
>а по одному из сопутствующих (причем иногда по одному -
>наименование, а иногда по другому - цена, а может быть еще по
>третьему, четвертому и т.д.).
И в чем проблема-то ? (некорректный)
>А на форму (справочник в гриде) можно положить фильтр,
>переупорядочить по любой колонке, использовать куда более >мощные, чем в комбобоксе, средства поиска.
Это все можно сделать и при корр-ке в гриде. (слабый)
>Я уже не говорю о возможности тут же добавить в спр-к новую
>запись.
Никаких проблем при работе с гридом. (слабый)
Я, конечно, понимаю, что это не совсем аргументы, но разжевывание реализации приведенных фич есть спам для ветки...
| |
Страницы: 