Помогите с сохранением информации в БД InterBase (Delphi)

← →
Zergik (2006-05-10 12:01) [0]

Помогите пожалуйста решить такую проблему.
Есть товар с множеством характеристик. Чтоб не загружать этими характеристиками одну таблицу, я их разбил на несколько категорий (в разные таблицы со связью один-к-одному)
Как правильно обеспечить сохранение и обновление информации из приложения, так как информация в приложении подвергается частым изменениям, причем эти изменения могут происходить сразу в разных таблицах(т.е изменения сделанные в одной категории свойств влияют на свойства другой категории).
В совокупности всех свойств товара насчитывается около 150-170, и обновлять каждое поле мне кажется "не есть правильным".
Информацию по конкретному товару я получаю с помощью SQL запроса (SELECT * поля таблиц FROM все таблицы WHERE соответствуют первичные ключи).
Есть ли какие-то методы для обновления всего набора данных сразу. Если нет, то подскажите как это сделать правильно обычными методами.
Заранее благодарен за помощь.

← →
Desdechado © (2006-05-10 12:05) [1]

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

удобно для расширения списка свойств, но плохо для контроля целостности БД, т.к. нельзя нормально отследить обязательность полей и т.п.

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

← →
Sergey13 © (2006-05-10 12:07) [2]

2Zergik (10.05.06 12:01)
>Чтоб не загружать этими характеристиками одну таблицу, я их разбил на несколько категорий (в разные таблицы со связью один-к-одному)
Если это просто "забота о худобе" таблицы - ты поступил опрометчиво, ИМХО.

← →
Zergik (2006-05-10 12:11) [3]

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

← →
Zergik (2006-05-10 12:16) [4]

+ ... большинство свойств в таблице - это текстовая информация (коды из справочников), но существует так же где-то 15 полей хранящих объемную текстовую информацию (до 100-120 символов)

← →
Desdechado © (2006-05-10 12:20) [5]

ограничение есть
http://www.ibphoenix.com/main.nfs?a=ibphoenix&l=;FAQS;NAME=%27System+Limits%27

почему коды - текстовые?

← →
Sergey13 © (2006-05-10 12:23) [6]

2[3] Zergik (10.05.06 12:11)
>существует ли какое-то ограничение на количество полей в таблице,
Наверное. Но ты его еще не достиг. 8-)

>и как большое количество свойств повлияет на быстродействие (базой пользуются несколько человек).
Положительно. Не надо джойнить несколько таблиц. Еще желательно не юзать Select * , а давать перечень нужных полей.

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

Ты бы описал задачку то. А то 150-170 свойств многовато все таки на первый взгляд.

← →
Zergik (2006-05-10 12:41) [7]

Извиняюсь - ошибся - коды числовые (integer)
... а на счет задачи:
оформление заказа по выпусу дверей

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

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

← →
Desdechado © (2006-05-10 12:45) [8]

UPDATE tbl SET ручка=3 WHERE дверь=5

заказы - отдельно
содержимое заказов - отдельно

почитай про правила нормализации, нормальные формы

← →
Sergey13 © (2006-05-10 12:53) [9]

2[7] Zergik (10.05.06 12:41)
Ну

>категории, фасоны, цвета, габариты, дополнительные требования,

Я еще могу (с оговорками) к свойствам отнести.

Но
>комплектация (замки, ручки, глазки и т.д.), + калькуляции, плюс технический процесс (где на каком участке находится изделие, когда оно на него пришло, когда выйдет...)

Это уж увольте.

Тебе с проектированием надо разбираться и разбираться.

← →
Zergik (2006-05-10 13:00) [10]

... я что-то не пойму - то советовали все объеденить в одну строку, то "заказы - отдельно, содержимое заказов - отдельно".???
... может я неправильно выразился, и по-этому хочу заметить, что каждая из вышеперечисленных характеристик является уникальной для каждого заказа.

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

← →
Sergey13 © (2006-05-10 13:02) [11]

2[10] Zergik (10.05.06 13:00)
>... я что-то не пойму ...
Потому и вопросы подобные возникают. 8-)

← →
Desdechado © (2006-05-10 13:04) [12]

"советовали все объединить в одну строку" - это только для свойств, к коим относится, например, фамилия заказчика, дата, его р/с и т.п.
а в заказе может быть несколько дверей - и это уже не 1-к-1
а у двери может быть несколько замков, но не быть глазка или 2 глазка (под оба глаза :)
и каждая дверь заказа может быть на разной стадии изготовления
так что тут тоже не 1-к-1
это уже нормальная БД со связями 1-ко-многим
и логика уже посерьезней, чем изменение поля одной таблицы

← →
Zergik (2006-05-10 13:06) [13]

to Sergey13
Пример заказа:

Код заказа
Заказчик
Дата заказа
Срок изготовл.
Материал наружный
Материал внутренний
Фасон наружный
Фасон внутренний
Цвет наружный
Цвет внутренний
Открывание - левое
Сворок - 2
Направление - наружу
Замок1 - Моттура 65487
Замок2 - нет
Цилиндр - Чиза
...
...
Доп. требование 1 - "ххх"
Доп. требование 2 - "ххх"
Доп. требование 3 - "ххх"
Доп. требование 4 - "ххх"
Доп. коэф. на цену
Цена
Скидка

← →
Zergik (2006-05-10 13:08) [14]

... ОДИН ЗАКАЗ - ОДНА ДВЕРЬ

← →
Desdechado © (2006-05-10 13:11) [15]

т.е. я не могу заказать сразу 2 двери? разных?

а если вы начнете делать окна?

ну-ну, лучше учись, а не противься...

2 [13] Zergik (10.05.06 13:06)
>Скидка
А если их несколько? С разным порядком применения + суммарная скидка не должна превышать Х%?

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

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

← →
Zergik (2006-05-10 13:18) [18]

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

и окна мы делать не будем!!!

Задача всего этого дела - создать менеджер заказов, так как контролировать все на "писульках" для большого обьема производства не получится.

2[18] Zergik (10.05.06 13:18)
По твоей "структуре" данных тебе больше подойдет Ексель, а не БД.

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

atruhin © (10.05.06 13:32) [20]
как-как, еще 150 полей, 75% который в большинстве дверей не будут заполнены
ведь если максимально возможно 10 вставок, то под них дырки и выделят
видел я такие базы
и горько видеть было

автору
ведь реляционные БД придуманы именно для хранения отношений в таблицах (т.е. связей их между собой)
и таблица - удобный способ хранения данных в столбик, а не в строку
помни об этом

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

Помогите с сохранением информации в БД InterBase (Delphi) Найти похожие ветки