Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Избежание переполнения таблиц [D6, IB5.x, IB6.x]

Страницы: < 1 2 3 4 >
Nick-From © (2003-09-05 14:18:00)

Есть таблица товаров на складе:

1. id товара (unique)
2. наименование товара
3. дата изготовления товара
4. дата срока годности товара
5. текущее кол-во товара на складе
6. текущая цена товара

Так же есть таблицы приходных и расходных накладных для учета покупки/продажи товаров.

Приходные накладные:
1. id накладной (не unique, т.к. одна накладная может содержать нескоько товаров);
2. id товара
3. дата оприходования
4. поставщик
5. кол-во купленного
6. цена, по которой закупили

Расходные накладные:
1. id накладной (не unique, т.к. одна накладная может содержать нескоько товаров);
2. id товара
3. дата списания
4. покупатель
5. кол-во проданного
6. цена, по которой продали

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

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

Мастера, подскажите, как решить, можт по-другому организовать таблицы как-то? Два дня вот соображаю - никак. Или это и не страшно, что нет удаления, хотя навряд-ли.

HSolo (2003-09-08 16:01:00) [41]

Можно и так - если: 1) таблицу вести триггерами, никому для прямого редактирования ее не давать и 2) корректно рулить транзакциями

-=GUEST=- (2003-09-08 15:51:00) [42]

А как все-таки лучше организовать остатки ?
Есть такая бух. программа - GrossBee, я брал её базу когда IB изучал (рекомендую).
Организуется таблица WAREREST, приблизительно
ID_Tovara
ID_Sklada (у них мультискладской учет)
Ostatok
Rezerv
В которую в процесе работы вносятся изменения, типа
Ostatok = Ostatok - Rashod
Ostatok = Ostatok + Prihod
Естественно не так просто, но идея такая.
На сколько это правильно.
Это самая простая реализация.
Интересно что будет если одновременно вносят изменения два пользователя.

Nick-From (2003-09-05 19:54:00) [43]

Всем большое спасибо за обсуждение!

2 roottim
>не завязывай явно на товар... журнал накладных делай автономным
> 2.1 наименование
А если захочется посмотреть какого срока годности был товар или еще чего, ну фото и т.д., то надо тогда полями 2.2; 2.3; оформлять - дублировать т.е. или не включать такую возможность вообще.

Действительно, схема HSolo мне понравилась гораздо больше :) Буду плясать от нее. tnx 2 HSolo :)

2 Рамиль
> как у вас остатки построены, интересно прос то было бы узнать...
Да никак :) Это мне надо просто лабу сделать по СУБД на IB. Вот взял такую предметную область, хоть как-то ближе к жизни чем подсчет успеваемости студентов :) вот уже и про приход товаров по накладным узнал и про динамику движения товаров за несколько лет :))

Если у кого еще какие предложения, буду только рад выслушать, еще раз всем спсибо!

MsGuns (2003-09-05 16:26:00) [44]
ИМХО, стоит прислушаться к Рамиль © & HSolo ©
Хотя модель, приводимая очень упрощенная, но она - живая. Тот же каркас, что в сабже - мертворожденный и при достаточно большом движении просто "задохнется".

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

Vlad (2003-09-05 16:24:00) [45]

>andrey__ (05.09.03 15:57) [14]
Зависит от типа СУБД и наличии места на диске.
В Аксессе, например, как мне тут недавно подсказали, объем базы м.б. не более 2 ГБ.

andrey__ (2003-09-05 16:21:00) [46]

да ну сабок коты лучше

кото нибуть мне ответит.

Рамиль (2003-09-05 16:00:00) [47]

> собак я конечно не ел, но на вкус и цвет

Да ты их просто готовить не умеешь:)

> HSolo

Желательна такая цепочка:
Документ основание, накладная, ордер.
В ДО делается резирвирование, после чего создается накладная, при ее списании резерв из ДО сбрасывается.
Прайсов должно быть несколько штук (действующие, в разработке и т. д.)
Накладные можно не разделять, а просто выделить поле под тип накладной.
И Nick-From, а как у вас остатки построены, интересно прос то было бы узнать...

andrey__ (2003-09-05 15:57:00) [48]

Извините, что вмешиваюсь, хотелось бы узнать, сколько максимум записей может вместить SQL таблица и от чего это зависит.

У меня есть таблица в которой 3.500.000 записей и она постоянно наращивается.

HSolo (2003-09-05 15:39:00) [49]

Может, лучше так:

Номенклатура
1. id товара (unique)
2. наименование товара
(что там еще – фотография, характеристики...)

Приходные накладные:
1. id накладной (unique)
2. номер накладной
3. дата оприходования
4. поставщик

Приход товаров по накладным
1. id прихода (партии товара) (unique)
2. id товара
3. id накладной
4. кол-во купленного
5. цена, по которой закупили

Прайс-лист
1. id строки в прайсе (unique)
2. id товара
3. цена реализации
(что там еще – дата начала действия, скидки, условия...)

Расходные накладные:
1. id накладной (unique)
2. номер накладной
3. дата списания
4. покупатель

Расход товара по накладным
1. id расхода (unique)
2. id накладной
3. id прихода
4. кол-во проданного
5. цена, по которой продали

Это очень упрощенная схема. Скорее всего, Вам понадобится (не сейчас, так потом) резервирование товара, заказ и много чего еще :)
А почему Вы опасаетесь переполнения таблиц? У Вас очень большой объем информации?

Polevi (2003-09-05 15:34:00) [50]

>DenK_vrtz © (05.09.03 15:05) [10]
геморой легче заработать с архивными таблицами, все зависит от колва записей
у меня 2,5 милиона и никаких архивов

Vlad (2003-09-05 15:30:00) [51]

Архивные таблицы это правильно с точки зрения построения системы.
Но ребяты, посчитайте сами. Пусть даже в день проходит по тысяче накладных. Так за 10 лет это 3 млн записей получится. При наличии индексов в базе - запросы пулей свистеть будут... ну почти пулей.

DenK_vrtz (2003-09-05 15:05:00) [52]

Polevi ©, но согласись, что с организованными архивной(ыми) таблицой(ми) легче и быстрее работать?

Рамиль ©, собак я конечно не ел, но на вкус и цвет..., сам понимаешь :-) О правильной организации данных никто, заметь, не спорит! :-)

Рамиль (2003-09-05 15:01:00) [53]

> DenK_vrtz ©

Я на корпоративных системах собаку съел.
Делать отчет по нескольким таблицам, должно быть одно удовольствие...

Polevi (2003-09-05 14:55:00) [54]

не нужно ничего удалять, посчитай сколько у тебя записей будет через 10 лет

DenK_vrtz (2003-09-05 14:48:00) [55]

Рамиль ©, организовать архивную(ые) таблицу(тыблицы) по годам!

Рамиль (2003-09-05 14:41:00) [56]

> теоретически, база в конце года должна скидаваться в архив
>

А как получать динамику движения товаров за несколько лет?

Mike Kouzmine (2003-09-05 14:38:00) [57]

Ты продал товар и забыл? (Удалил карточку). Забавно.

Рамиль (2003-09-05 14:38:00) [58]

> не завязывай явно на товар... журнал накладных делай автономным

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

DenK_vrtz (2003-09-05 14:38:00) [59]

Nick-From ©, Vlad © (05.09.03 14:20) [1] дело говорит + теоретически, база в конце года должна скидаваться в архив и чистится (удаляется отработанный материал). Как ты это организуешь - твое право!

roottim (2003-09-05 14:33:00) [60]

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

Расходные накладные:
1. id накладной (не unique, т.к. одна накладная может содержать нескоько товаров);
2. id товара
2.1 наименование
3. дата списания
4. покупатель
5. кол-во проданного
6. цена, по которой продали

Страницы: < 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »