| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / 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-10-25 15:26:00) [21]Delirium © (25.10.02 15:10)> 5-й пункт для клиент/сервер не обязателен. Фильтры спасут от перегрузок :)
MsGuns (2002-10-25 15:17:00) [22]>Delirium © (25.10.02 15:10)
Я бы еще добавил
6)Права - определяют диапазон функций (прав) специализированных клиентов (т.е. директору-директорово, бухгалтеру-бухгалтерово) и прав к доступу к данным
Delirium (2002-10-25 15:10:00) [23]> Johnmen ©
"А вот в реальности иногда приходится и понижать" - Согласен, иногда приходится (к сожалению), однако это уже больше творчество чем наука - предугадывать возможные расширения и строить проект в соответствии с ними. Возвращаясь к автору ветки, дам ещё несколько советов, возможно пересекающихся с пердыдущими ораторами. Необходимо чётко разделять по структуре и по нотации следующие объекты БД:
1) Справочники (идентификатор, значение)
2) Связи (cross table) (идентификатор_справочника_1, идентификатор_справочника_2) - лучше создавать отдельный кросс для каждой пары спавочников
3) Документы (master->detail) - лучше не создавать более чем двух-уровневые документы
4) Агрегаты (вычисления по документам) - следует увязать на триггерах, дабы ускорить рассчёты на больших таблицах
5) Истроии (точные копии вышеозначенных таблиц с дополнительным ключом)
Думается, если придерживатья такой методики, получить высоко-нормальную базу не проблема, даже на очень сложных проектах.
MsGuns (2002-10-25 14:58:00) [24]>Johnmen © (25.10.02 14:09)
>MsGuns © (24.10.02 20:02)
>По поводу использ.формы редактирования вместо грида - согласен,
>но аргументы, тобой приводимые, весьма слабы, а некоторые просто некорректны...
Ну, с аргументами у меня вообще сплошные траблы (ЁМХО)
Особенно если их не утружаются не то что аргументированно
опровергнуть, но даже прочитать и постараться понять.
Alex Chu (2002-10-25 14:45:00) [25]Теперь можно всем пожать лапки!
Без полноценного ТЗ даже начинать работу НЕЛЬЗЯ!
И поверте, MsGuns ©, это далеко не 50%...это БОЛЬШЕ!
Кодеров сейчас тучи, а программеров и Постановщиков мало!
MsGuns (2002-10-25 14:41:00) [26]Так в чем проблема ? Берите постановку сами ! Нормальные огурцы так и делают. А от заказчика (клиента) нужны только ИСХОДНЫЕ ТРЕБОВАНИЯ. Нормально сработанное ТЗ - как min 50% всего объема работы.
Johnmen (2002-10-25 14:35:00) [27]>Alex Chu (25.10.02 14:21)
Абсолютно точное замечание !!!
>...задачи ставят люди, мало разбирающиеся ...
Зачастую, просто НЕразбирающиеся !!! И не могущие в принципе формализовать задачу...
Ops (2002-10-25 14:29:00) [28]В справочниках введи код - видимый(удобный) для человека. И пусть человек вводит код в поле а не осмысленное значение. И скорее всего эти коды уже есть. К примеру бугалтера помнят на вскидку более 100 кодом основных для заполнения их в бумажках...
А если он не помнит кода в справочнике пусть уж озадачится полноценным поиском в отсортированном списке...
Такую задачу мне поставили на производстве - для нормоконтрлеров.. А коды они распечатывали и вешали рядышком на рабочем месте.
Alex Chu (2002-10-25 14:21:00) [29]Если говорить о принципах проектирвоания БД, то говорить больше приходится о качестве ТЗ и Грамотности (образования и опыта) Постановщика задачи.
Но у нас в стране, зачастую, задачи ставят люди, мало разбирающиеся в аспектах Программирования и Структур БД в частности.
Следовательно - первым шагом в момент разработки ТЗ должен быть поиск человека, который знаком с особенностям работы программистов и с Сутью проблемы в организации, которую хотят решить (упростить), говоря об автоматизации процессов.
Какая, б.., нормализация в этот период?!!
MsGuns (2002-10-25 14:15:00) [30]>Delirium © (25.10.02 13:55)
Боюсь опять навлечь на себя гнев монстров БД, но заявлю категорично.
Задача построения графов (а состав изделий - это как раз из этой серии) на БД с НЕИЕРАРХИЧЕСКОЙ структурой ФИЗИЧЕСКОГО хранения информации - является нормализуемой лишь частично ! Можно нормализовать узлы (т.е.детали, сборки и т.д.), но никак не СВЯЗИ МЕЖДУ НИМИ. Хотя бы потому, что они носят весьма временный характер из-за большого кол-ва конструкторско-технологических изменений. Также ИМХО
Johnmen (2002-10-25 14:09:00) [31]>MsGuns © (24.10.02 20:02)
По поводу использ.формы редактирования вместо грида - согласен,
но аргументы, тобой приводимые, весьма слабы, а некоторые просто некорректны...
>Delirium © (25.10.02 13:55)
>В общем, я считаю, что степень нормализации должна
>закладываться при логическом проектировании БД и в дальнейшем
>не понижаться, ...
Твоими устами, да мед пить !
А вот в реальности иногда приходится и понижать (по мере возрастания аппетитов заказчика)....
Delirium (2002-10-25 13:55:00) [32]> Sergey13 ©
Я не возвожу нормализацию в неукоснительную и, по большому счёту, абстрактную догму. Разумеется идеально нормализованых БД в природе не существует, а если бы и были - работа с ними превратилась бы в большую проблему, чем обеспечение целостности, формализации, экономии ресурсов и других нрмальных достоинств. Я ведь указал на необходимую и достаточную степень нормализации, так как далнейшие ухищрения - тема для диссертаций, а не для практической работы. В общем, я считаю, что степень нормализации должна закладываться при логическом проектировании БД и в дальнейшем не понижаться, это конечно IMHO ;)
kserg@ukr.net (2002-10-25 10:17:00) [33]Спасибо >[NIKEL] ©
и >MsGuns © (24.10.02 20:02)
очень точно описал суть задачи - сразу вижу, что сталкивался с подобным. Действительно, ко всему прочему наварачивается задача входимости(построение дерева), но от данной задачи я пока отказался.
Если рассмотреть источник проблем в решении данной задачи - это поиск компромиса между требованиями достоверности данных(ведение кучи справочников), простотой ввода и теми сроками, котр. мне ставят на выполнение данной задачи...
Sergey13 (2002-10-25 10:05:00) [34]2Delirium © (24.10.02 18:41)
>.. любая современная реляционная БД должна и обязана быть доведена до 3S нормальной формы
Позволю себе не согласиться. ИМХО прав Johnmen ©. Нормализация не догма и не цель, а только метод позволяющий избежать избыточности данных. Придумывалась эта штука во времена когда мегабайт памяти стоил лимон баксов. С тех пор мир сильно изменился. И для улучшения производительности (например) можно применять и ДЕнормализацию(то же кстати метод описанный в литературе).
MsGuns (2002-10-24 20:02:00) [35]Справочники - это, конечно, проблема (вернее, проблема создания их интерфейса), но главные проблемы в этом проекте - совсем не они ! Я понял, что надо держать состав изделий и ПКИ к ним. Вот это и естьГЛАВНАЯ проблема, т.к. там может быть древо, да еще какое ветвистое 8). И с заявками тоже будут траблы те еще. Особенно если учитывать комплекты.
А на счет справочников - ИМХО, Val © (24.10.02 18:18)
дал дельный совет. И НИКАКИХ КОМБОБОКСОВ на БОЛЬШИЕ или многоколоночные справочники. В гриде с такими справочниками не работа, а мУка. Пока найдешь что надо, кинешь все на фиг. Первые буквы не походят, т.к. искать надо не по ключевому полю, а по одному из сопутствующих (причем иногда по одному - наименование, а иногда по другому - цена, а может быть еще по третьему, четвертому и т.д.). А на форму (справочник в гриде) можно положить фильтр, переупорядочить по любой колонке, использовать куда более мощные, чем в комбобоксе, средства поиска. Я уже не говорю о возможности тут же добавить в спр-к новую запись.
Но, повторюсь, это для СЛОЖНЫХ СПРАВОЧНИКОВ:
- больших по кол-ву записей
- имеющих большое кол-во сопутствующих полей
- состоящих их более чем одной таблицы (например, справочник бух.операций и сложных проводок к ним)
- требующих добавление (не удаление и не правку) "на лету"
[NIKEL] (2002-10-24 19:55:00) [36]Определись с понятиями, я делал так
есть такое понятие как ОПЕРАЦИЯ и соответственно таблица операция
у операции есть такие атрибуты как:
тип операции (призод, расход, списание, ввод нач. остатков и т.д.)
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
Также есть таблицы справочники, агенты, счета, банки, ГТД, группы товаров, товары, цены для товара, ед. измерения для товаров, договора, склады и т.д.
на самом деле я писал большую систему где много разных нюансов
Может скоро напишу статью, о том как я писал базу данных для магазина Автомобил. Запчасти и Клиента к ней :)
Xenon (2002-10-24 19:44:00) [37]ID-коды использовать все-таки придется.
Чтобы выбирать значения используй компонент TRxDBLookupCombo
из библиотеки RxLib. Очень удобно.
Delirium (2002-10-24 19:14:00) [38]"...чё-нибудь попроще..." - это не то, чем должен руководствоваться профессионал (или желающий таковым стать) в области БД.
kserg@ukr.net (2002-10-24 18:57:00) [39]Спасибо уважаемым знатокам.
Признаюсь надеялся услышать чё-нибудь попроще и при этом работоспособное решение
:(
Delirium (2002-10-24 18:41:00) [40]> Johnmen ©
Не углубляясь в теорию нормализации, смею утверждать, что любая современная реляционная (удовлетворяющая 12-и правилам Кодда) БД должнаи обязанабыть доведена до 3S нормальной формы (Бойса-Кодда) - Ни первичный ключ, ни какая-либо его часть не должны зависеть от не ключевого атрибута.
| |
Страницы: 