Правильное сохранение при Мастер- Детаил

← →
Xmen (2009-03-26 07:16) [0]

Привет мастерам.
Делаю программу для склада. Сделал таблицы для прихода товара. Установил связь мастер - детаил. Вопрос в том что если создать форму и поместит в нем 2 грида, один мастер другой детаил то при вводе мастер все нормально но в детаил таблицу ввод не получается изза того что не сохранен данные в мастер таблице. Как можно сохранит сразу и мастер и детаил без commit таблицы мастера?

← →
Sergey13 © (2009-03-26 08:23) [1]

1. Не надо делать приложение с БД отталкиваясь на пользовательский интерфейс.
2. Связь МД ты установил, но видимо до конца не понимаешь что это такое.
3. Пользуясь транзакциями можно обновить всю базу без коммита.
4. Для ИБ/ФБ обычно сначала получают мастер-ИД отдельным запросом, потом вставляют его в нужные места.

← →
Сергей М. © (2009-03-26 08:26) [2]

А сколько и каких у тебя задействовано транзакций ?

← →
Xmen (2009-03-26 08:37) [3]

> Sergey13 © (26.03.09 08:23) [1]
> 1. Не надо делать приложение с БД отталкиваясь на пользовательский
> интерфейс.2. Связь МД ты установил, но видимо до конца не
> понимаешь что это такое.3. Пользуясь транзакциями можно
> обновить всю базу без коммита.4. Для ИБ/ФБ обычно сначала
> получают мастер-ИД отдельным запросом, потом вставляют его
> в нужные места.

Мне просто интересно как это в пользовательское форме реализовать. У меня связь нормально работает. Вот как создал таблицы.
CREATE TABLE PRIHOD (
ID INTEGER NOT NULL,
PRINAKNUM INTEGER,
PRIDATE DATE,
PRISUMMA NUMERIC(15,2),
PRINYAL VARCHAR(30),
SDAL VARCHAR(30)
);
ALTER TABLE PRIHOD ADD CONSTRAINT PK_PRIHOD PRIMARY KEY (ID);

CREATE TABLE PRI_SPISOK (
ID INTEGER NOT NULL,
PRI_ID INTEGER NOT NULL,
NAME VARCHAR(50),
ED_IZM INTEGER,
SENA NUMERIC(15,2),
KOLICHESTVO INTEGER,
SUMMA NUMERIC(15,2)
);
ALTER TABLE PRI_SPISOK ADD CONSTRAINT PK_PRI_SPISOK PRIMARY KEY (ID);
ALTER TABLE PRI_SPISOK ADD CONSTRAINT FK_PRI_SPISOK_1 FOREIGN KEY (PRI_ID) REFERENCES PRIHOD (ID) ON DELETE CASCADE ON UPDATE CASCADE;
Здесь без сохранения первой таблицы неможно работать с второй таблицей изза того что еще нету внешнего ключа prihod(id)

← →
ЮЮ © (2009-03-26 08:41) [4]

> Для ИБ/ФБ обычно сначала получают мастер-ИД отдельным запросом,
> потом вставляют его в нужные места

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

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

← →
Виталий Панасенко(дом) (2009-03-26 08:42) [5]

Еще
> Sergey13 © (26.03.09 08:23) [1]

> 4. Для ИБ/ФБ обычно сначала получают мастер-ИД отдельным
> запросом, потом вставляют его в нужные места.

зависит от версии "птицы".. в 2.х появилась конструкция RETURNING, с помощью которой можно узнать, что сделал триггер(например, сгенерил тот же ИД) без отдельного запроса. Правда, IBX не совсем это поддерживают.ФИБы - без проблем. и у FIBPlus для мастер-детали много приятных вкусностей предусмотрено(подстановка автоматом мастер ИД, пауза при открытии детали(когда пробегаешь по мастеру в поисках нужной записи), автоматическое открытие детали при открытии мастера (нет необходимости явно в коде указывать Detail.Open())). + две транзакции на каждый датасэт одна длинная на чтение, другая, короткая на изменение данных.

← →
Xmen (2009-03-26 08:48) [6]

И что вы посоветуйте?

← →
Виталий Панасенко (2009-03-26 09:00) [7]

> Xmen (26.03.09 08:48) [6]
>
> И что вы посоветуйте?

А что ты используешь? Компоненты, версия ФБ... тяжело указать или секретная инфа

← →
MsGuns © (2009-03-26 09:00) [8]

← →
Sergey13 © (2009-03-26 09:03) [9]

> [4] ЮЮ © (26.03.09 08:41)

написал "обычно" вот поэтому

> [5] Виталий Панасенко(дом) (26.03.09 08:42)

> [6] Xmen (26.03.09 08:48)

А что еще не ясно?

← →
Виталий Панасенко (2009-03-26 09:04) [10]

> Sergey13 © (26.03.09 09:03) [9]

А фиг его знает!:-)

← →
Сергей М. © (2009-03-26 09:07) [11]

> изза того что еще нету внешнего ключа prihod(id)

Что мешает получить ключ для вставки новой записи в мастер-таблицу до вставки ?

← →
ЮЮ © (2009-03-26 09:13) [12]

>
> Что мешает получить ключ для вставки новой записи в мастер-
> таблицу до вставки ?

До вставки записи в мастер таблицу помешает
CONSTRAINT FK_PRI_SPISOK_1 FOREIGN KEY (PRI_ID) REFERENCES PRIHOD (ID)
:)

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

← →
Сергей М. © (2009-03-26 09:20) [13]

> ЮЮ © (26.03.09 09:13) [12]
>
>

Причем здесь констрейнт детайл-таблицы ?
Я о вставке в мастер-таблицу..

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

← →
Sergey13 © (2009-03-26 09:22) [14]

+ немного не по теме 8-)

> [0] Xmen (26.03.09 07:16)
> Сделал таблицы для прихода товара.

Удали ее или переименуй в таблицу ДВИЖЕНИЯ. А то еще придется создавать таблицы расхода, списания и т.д. и т.п.

← →
Xmen (2009-03-26 09:23) [15]

Я пользуюсь FB1.5 для связи пользуюсь InterBase компонентой.
> ЮЮ © (26.03.09 09:13) [12]
> > > Что мешает получить ключ для вставки новой записи в
> мастер-> таблицу до вставки ?До вставки записи в мастер
> таблицу помешает CONSTRAINT FK_PRI_SPISOK_1 FOREIGN KEY
> (PRI_ID) REFERENCES PRIHOD (ID) :)У авторра проблема в том,
> что забитые в детайл-гриде записи датасет пытается сразу
> засунуть в таблицу, а они должны быть вставлены после записи
> в основную, которая должна произойти только после того,
> как пользователь вобьёт несколько детайл-записей и нажмет
> кнопку "сохранить"

А как можно это тогда по другому сделать? Что можете посоветовать?

← →
ЮЮ © (2009-03-26 09:40) [16]

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

У человека проблема не с первичным ключом, а с невозможностью вставить в детайл, пока не вставлена запись в мастер.

А вставлять сразу ему не нужно. Ему нужно вставить скопом: 1-у в мастер и несколько в детайл.

← →
Виталий Панасенко (2009-03-26 09:40) [17]

Установить CashedUpdates=True в обоих НД.. для мастера ОТДЕЛЬНЫМ запросом получить ИД. Добавить в мастер, подставив полученный ИД. Сделать POST(данные при этом не будут записаны в БД). Заполнить деталь, подставив полученный ИД для мастера.. сделать ApllyUpdates для мастера, затем детали. что-то в этом виде.. где-то так.. либо без кеширования: всегда постить мастера, получить его ИД и далее использовать для детали

← →
Сергей М. © (2009-03-26 09:59) [18]

> ЮЮ © (26.03.09 09:40) [16]
>
>

Как это не вставлена ?
Насколько я понял, вставлена, т.е. Post выполнен, но ТА еще не подтверждена (см. упоминание Commit)

Т.е. для вставки в подчиненную таблицу достаточно знать ID только что вставленной мастер-записи и выполнять вставку в подчиненную таблицу в той же ТА, в которой была выполнена вставка в мастер-таблицу.

← →
MsGuns © (2009-03-26 10:05) [19]

>Xmen (26.03.09 09:23) [15]
>Я пользуюсь FB1.5 для связи пользуюсь InterBase компонентой.

Вполне достаточно. ФИБплас сделан для криворуких и ленивых

>А как можно это тогда по другому сделать? Что можете посоветовать?

Делать по стандартной схеме, не выдумывая велоспипеда

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

Все это имеется и вполне добросоветсно работает в 1С - если так уж неодолимо желание самому написать складскую прожку, имеет смысл хотя бы внимательно ознакомиться как это сделано там.

← →
Xmen (2009-03-26 10:26) [20]

> Sergey13 © (26.03.09 09:22) [14]
> + немного не по теме 8-)> [0] Xmen (26.03.09 07:16)> Сделал
> таблицы для прихода товара.Удали ее или переименуй в таблицу
> ДВИЖЕНИЯ. А то еще придется создавать таблицы расхода, списания
> и т.д. и т.п.

Как?

← →
Sergey13 © (2009-03-26 10:36) [21]

> [20] Xmen (26.03.09 10:26)

Что как?

← →
MsGuns © (2009-03-26 10:46) [22]

>Xmen (26.03.09 10:26) [20]
>Как?

Добавить в таблицу документов поле "Тип документа", куда помещать "П" для приходов, "У" - возврат поставщику, "Р" - реализация, "В" - возвраты от покупателей, "С" - списание, "О" - переоценка(дооценка, уценка).. и поле "Баланс", содержащее фактически знак (1 или -1), задающий приход или списание на/с карточки. (Последнее необязательно если движение фиксируется на карточке уже с правильным знаком)

← →
Sergey13 © (2009-03-26 11:00) [23]

> [22] MsGuns © (26.03.09 10:46)
> куда помещать "П" для приходов, "У" - возврат поставщику

Все таки правильнее наверное будет помещать туда ссылку на таблицу операций, ИМХО.

← →
Xmen (2009-03-26 12:08) [24]

Ну тогда для каждого запися нужно писать или указывать повторяющийся записей наименование поставщика, номер накладного, дату и др. для каждого запися.

← →
Sergey13 © (2009-03-26 12:11) [25]

> [24] Xmen (26.03.09 12:08)

С чего бы это?

← →
Сергей М. © (2009-03-26 12:23) [26]

> для каждого запися

> номер накладного

"Запись" и "накладная"- она вообще-то женского рода).. По кр.мере, в русском языке

← →
Anatoly Podgoretsky © (2009-03-26 13:52) [27]

> 1c

dbf или ms sql или три кольца?

← →
Anatoly Podgoretsky © (2009-03-26 13:56) [28]

Нет бесхозным записям!
Сначала мастера, а потом детали.
Хозяин без деталей может быть, а наоборот это уже бардак, по другому порушеная база.
И все речь вокруг транзакций, но мастера вперед.

← →
Xmen (2009-03-26 13:59) [29]

> Сергей М. © (26.03.09 12:23) [26]
> > для каждого запися> номер накладного"Запись" и "накладная"-
> она вообще-то женского рода).. По кр.мере, в русском языке

Наверно плохо знаю.

> Sergey13 © (26.03.09 12:11) [25]
> > [24] Xmen (26.03.09 12:08)С чего бы это?

Ну для склада я понимаю нужно организовать минимум 5 таблиц.
1. Приход. Номера накладных, договоров, фирмы продавца и др.
2. Приход по товаров. Наименование товаров, единицы, цен и сумма.
3. Расход.
4. Расход по товаров. Наименование товаров, единицы, цен и сумма.
5. Книга движений.
Или можно по другому?

← →
Xmen (2009-03-26 14:05) [30]

> Anatoly Podgoretsky © (26.03.09 13:56) [28]
> Нет бесхозным записям!Сначала мастера, а потом детали.Хозяин
> без деталей может быть, а наоборот это уже бардак, по другому
> порушеная база.И все речь вокруг транзакций, но мастера
> вперед.

Я тоже так думаю но как быть? Без получения id значения невозможно сохранить детаил поле. Вед id генерируется после сохранения поля в мастере.

← →
Sergey13 © (2009-03-26 14:13) [31]

> [29] Xmen (26.03.09 13:59)
> Или можно по другому?

Нужно!
1. Документы на движение.
2. Товары в документах на движение
3. Операции в документах на движение - это справочник на несколько записей, где будет ИД, название операции и поле направления движения (+1 или -1), на которое надо умножить количество товара, что бы оно прибавилось или списалось с остатка.

← →
Сергей М. © (2009-03-26 14:47) [32]

> для склада .. нужно организовать минимум 5 таблиц

Если шарашкина контора, то и одной достаточно.

← →
Виталий Панасенко (2009-03-26 14:54) [33]

> Xmen (26.03.09 14:05) [30]

Так, а что мешает этот самый ИД(идентификатор) получить? по-моему, абсолютно ничего...

← →
Sergey13 © (2009-03-26 14:58) [34]

> [30] Xmen (26.03.09 14:05)
> Вед id генерируется после сохранения поля в мастере.

ИД не генерируется. Генерируется значение генератора (тафтология однако 8-) которое прописывается в ИД. Когда генерируется - тебе решать.

← →
Xmen (2009-03-26 15:19) [35]

> Виталий Панасенко (26.03.09 14:54) [33]

Но для этого нужно сохранить мастер таблицу

← →
Xmen (2009-03-26 15:23) [36]

> Sergey13 © (26.03.09 14:58) [34]
> > [30] Xmen (26.03.09 14:05)> Вед id генерируется после
> сохранения поля в мастере.ИД не генерируется. Генерируется
> значение генератора (тафтология однако 8-) которое прописывается
> в ИД. Когда генерируется - тебе решать.

А как можно это сделать

← →
Виталий Панасенко (2009-03-26 15:32) [37]

> Xmen (26.03.09 15:23) [36]
>
>

См.
> Виталий Панасенко (26.03.09 09:40) [17]

← →
Виталий Панасенко (2009-03-26 15:33) [38]

> Xmen (26.03.09 15:19) [35]
>
>
> > Виталий Панасенко (26.03.09 14:54) [33]
>
> Но для этого нужно сохранить мастер таблицу

Я такого не говорил.

← →
Виталий Панасенко (2009-03-26 15:39) [39]

при CashedUpdates=True НИКАКИЕ ДАННЫЕ НЕ ПИШУТСЯ В БД ДО ВЫЗОВА ApplyUpdates соответствующего НД... сделай в OnNewrecord мастер НД получение ИД (отдельным реальным запросом, который "дергает" генератор (select gen_id(gen_name, 1) from rdb$database)
begin
GenQry.Open;
Master.FieldByName("ID").AsInteger := GetQry,FieldByName("GEN_ID_NAME").AsInteger;
end;
типа такого

← →
MsGuns © (2009-03-26 15:48) [40]

>Xmen (26.03.09 13:59) [29]

С ума застрелиться !
Товарысч не только писать, но и читать не умеет.
[19] вообще, а абзац про 1с в частности для кого писан был ?

Опять-таки прежде чем садиться писать всякие "мастер-деталы" неплохо бы поиметь какое-никакое представление о ПРЕДМЕТНОЙ ОБЛАСТИ ибо судя по ветке у автор в торговле не ухом, не рылом. Неплохо также подчитать что-нибудь по проектированию БД вообще, например про нормализацию (это к вопросу про "наименования" и т.д.)

Короче, лучшее решение - это 1С. Иначе это будет что-то страшное, а не прогроамма.

Ну а если нужно "поскорее" или "для папы", то эксель в зубы и вперед с песней

← →
Виталий Панасенко (2009-03-26 15:57) [41]

Я так и не понял, почему тебе так мучительно первоначально записать мастер запись? Получишь ИД и используй его уже в детали...

← →
Sergey13 © (2009-03-26 15:58) [42]

> [40] MsGuns © (26.03.09 15:48)

Да ладно тебе. 8-)

Мы все учились понемногу
Чему-нибудь и как-нибудь.
(с) Пушкин

ЗЫ: только наверное надо в соответствующий раздел переносить топик

← →
Сергей М. © (2009-03-26 16:02) [43]

> MsGuns © (26.03.09 15:48) [40]

Что-то тебя не понять)

То на "топорность" одноэсины сетуешь, то агитируешь народ за одноэсину как "лучшее решение")

← →
Anatoly Podgoretsky © (2009-03-26 16:48) [44]

> Сергей М. (26.03.2009 16:02:43) [43]

Чего странного то, ведь по знаниям, кому то умные программы, кому то тупые.

← →
MsGuns © (2009-03-26 16:51) [45]

>Сергей М. © (26.03.09 16:02) [43]
>Что-то тебя не понять)
>То на "топорность" одноэсины сетуешь, то агитируешь народ за одноэсину как "лучшее решение")

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

← →
Сергей М. © (2009-03-26 17:43) [46]

> MsGuns © (26.03.09 16:51) [45]

А, ну вот теперь понятно, с какой стороны "топор" рассматривается)

В целом согласен.

Но уж больно дорог этот "топор" оказывается в приобретении, саппорте и эксплуатации.

← →
MsGuns © (2009-03-26 22:22) [47]

>Сергей М. © (26.03.09 17:43) [46]
>Но уж больно дорог этот "топор" оказывается в приобретении, саппорте и >эксплуатации.

Скупой платит дважды (с)

← →
Игорь Шевченко © (2009-03-27 02:31) [48]

Потянуло 90-ми годами, когда каждый писал свои склад, бухгалтерию и отдел кадров, преимущественно на клиппере. Я думал, за 15 лет весь этот глючный зоопарк благополучно вымер вместе с носителями идей, ан нет, кому-то лавры старины покоя не дают, когда кажется, что написать свое много дешевле, чем купить готовое.

← →
Xmen (2009-03-27 06:46) [49]

А что тепер и написать программу ненужно?

← →
Anatoly Podgoretsky © (2009-03-27 09:08) [50]

Не нужно, особенно с такими знаниями.

← →
Сергей М. © (2009-03-27 09:14) [51]

> Скупой платит дважды

А бездумно щедрый четырежды)

← →
Xmen (2009-03-27 12:34) [52]

почитав ваши ответы изменил структуру таблиц.
Таблица движение товаров.
CREATE TABLE TOVAR (
ID INTEGER NOT NULL,
ID_DOC INTEGER,
NAME VARCHAR(100),
ED_IZ INTEGER,
SENA NUMERIC(15,2),
KOL INTEGER,
ID_OPER INTEGER
);
ALTER TABLE TOVAR ADD CONSTRAINT PK_TOVAR PRIMARY KEY (ID);

Таблица документов(приход/расход)
CREATE TABLE DOCUMENT (
ID INTEGER NOT NULL,
N_DOC INTEGER,
N_DOG INTEGER,
DATE_DOC DATE,
SUMMMA_DOC NUMERIC(15,2),
PRINIAL VARCHAR(50),
SDAL VARCHAR(50),
ORG VARCHAR(100),
TYPE_DOC INTEGER
);
ALTER TABLE DOCUMENT ADD CONSTRAINT PK_DOCUMENT PRIMARY KEY (ID);

Операции по товарам
CREATE TABLE OPERATION (
ID INTEGER NOT NULL,
ID_TOVAR INTEGER,
TYPE_OPER INTEGER,
DATE_OPER DATE
);
ALTER TABLE OPERATION ADD CONSTRAINT PK_OPERATION PRIMARY KEY (ID);

Правильно ли я создал?

> Правильно ли я создал?

Нет

> [52] Xmen (27.03.09 12:34)
> Правильно ли я создал?

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

> Таблица движение товаров.
Это товары в документе на движение, а не то что ты написал. Это принципиальная разница.

> N_DOG INTEGER,

> SUMMMA_DOC NUMERIC(15,2),
> PRINIAL VARCHAR(50),
> SDAL VARCHAR(50),
> ORG VARCHAR(100),
> TYPE_DOC INTEGER

Это что и зачем?

> ID_OPER INTEGER

Это относится к документу, а не к товару.

> DATE_OPER DATE

Это вообще зачем? Это маленький справочник, никаких дат там не нужно.

Ну и про то что я писал тебе в письме. Что и как учитывать будешь, определился? Без этого проектировать структуру бесполезно.

> Xmen (27.03.09 12:34) [52]

Смысл каждой записи в "книге движения" - тогда-то там-то на основании такого-то документа осуществлена такая-то операция над такой-то номенклатурно-учетной единицей в таком-то количестве для такой-то единицы измерения по такой-то учетной стоимости на такую-то сумму.

← →
Xmen (2009-03-27 14:18) [56]

TABLE TOVAR
ID - ид
ID_DOC - вк таблицы Document
NAME - наименование товара
ED_IZ - единица из.
SENA - цена товара
KOL - количество
ID_OPER - вк операции по товару

DOCUMENT
ID - ид
N_DOC - номер документа (приход/расход)
N_DOG - номер договора
DATE_DOC - дата документа
SUMMMA_DOC - сумма документа
PRINIAL - принял (ФИО)
SDAL - сдал (ФИО)
ORG - организация (приход/расход)
TYPE_DOC - тип (приход/расход)

TABLE OPERATION
ID - ид
ID_TOVAR - вк товар
TYPE_OPER - тип операции (приход/расход/списание)
DATE_OPER - дата операции

> [56] Xmen (27.03.09 14:18)
тогда уж так

TABLE TOVAR
ID - ид
ID_DOC - вк таблицы Document
NAME - наименование товара
ED_IZ - единица из.
SENA - цена товара
KOL - количество

DOCUMENT
ID - ид
N_DOC - номер документа (приход/расход)
ID_OPER - вк операции по товару
N_DOG - номер договора
DATE_DOC - дата документа
SUMMMA_DOC - сумма документа
PRINIAL - принял (ФИО)
SDAL - сдал (ФИО)
ORG - организация (приход/расход)

TABLE OPERATION
ID - ид
NAME_OPER - тип операции (приход/расход/списание)
OPER - +1/-1

выделенное в отдельные соответствующие справочники. Если учитываются договоры, то нужна отдельная подструктура для них, типа Организации-Договоры с организациями. В документах просто ссылка на договор.
Со справочником "товары" тоже может быть все намного сложнее.

Что за склад у тебя, что хранишь/учитываешь, для чего?

И где тут таблица, отражающая движение ?

← →
Xmen (2009-03-27 14:55) [59]

У меня по идей все таблицы, справочников еще не указал.
Таблица Tovar у меня является таблицей движения. а таблица Document то является таблицей данных о документах прихода и расхода (номер договора, кто принял товар, от куда ....). Operation - таблица операции по товару, расхода/списания.

← →
Xmen (2009-03-27 15:02) [60]

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

Автор, ну поймите же наконец что пока не будет в голове ясности о ПРЕДМЕТНОЙ ОБЛАСТИ, не появится четкое представление об таких объектах как МАТЕРИАЛЬНЫЙ ДОКУМЕНТ, КАРТОЧКА ТОВАРА, КОНТРАГЕНТ и т.д., все что делается будет торжеством ламеризма.

Блин, ну это все равно что проектировать автомобиль с формы колеса и вида панели приборов

> [59] Xmen (27.03.09 14:55)
> Таблица Tovar у меня является таблицей движения
Чума просто. 8-)

> [60] Xmen (27.03.09 15:02)
> сначала это был склад маленькой продуктовой базы, ну я хотел
> это использовать и в других случаях.

Типа по легкому бабла срубить?

Вобщем тебе надо разобраться с предметной областью. И с основными принципами проектирования БД, всякие там ключи, нормальные формы и т.п.
Без этого пока дальше двигаться смысла нет, ИМХО.

>Xmen (27.03.09 14:18) [56]

Просто критика:

>TABLE TOVAR

Судя по структуре попытка привязать стойло к лошади, т.е. товар к документу, в то время как нужно с точностью до наоборот. Ну если уж эта таблица предназначена для хранения товарного СПРАВОЧНИКА, то

а) цене в справочнике делать нечего, ибо она должна быть в КАРТОЧКЕ
б) отсутствует несколько важных характеристик товара, например принадлежность к группе (категории) товара, ссылка на прайс-листы и т.д.

>DOCUMENT
> N_DOC - номер документа (приход/расход)

В одном поле и номер и тип документа ? Это как ? У документа может быть более одного номера, например для приходов есть внеший (входящий) и внутренний (учетный). Иначе 1-го января все приходы будут нумерованы 1 или оригинальный номера будут утеряны, что чревато.

> N_DOG - номер договора
Аналогично. Если требуется аналитика по договорам (заявкам) следует определить в БД объект "Договор" ("Заявка" или "Заказ"), спроектировать его таблицы, а в документах использовать ссылки на них

> DATE_DOC - дата документа
Одной даты мало например для приходов. Накладная может быть выписана 1-м числом, а товар прибыл 2-го.

>SUMMMA_DOC - сумма документа
Одной суммы мало. Требуется еще как минимум одна - НДС. Кроме того неясно как поступать со скидками (надбавками) ?

>PRINIAL - принял (ФИО)
>SDAL - сдал (ФИО)
Опять фигня. Если приход, то одного ФИО мало и требуется еще номер и дата доверенности
Зачем два ФИО, если вполне достаточно одного - ведь двух ФИО на одном док-те быть не может

>ORG - организация (приход/расход)
Опять "рюшечки" :) Должон быть справочник контрагентов с полной инфой включая банковские реквизиты, дира, главбуха и т.д., а здесь опять-таки ссылочка

>TYPE_DOC - тип (приход/расход)

Мало ибо есть еще как минимум один тип - списание

>TABLE OPERATION
Даже не обсуждаю - полная профанация фестивалит :)
Если требуется вести журнал операций, то хотя бы нужно понять что это такое и с чем его едят - опять-таки марш к 1с

В целом "картина маслом" (с)
Выкрасить и выбросить :)

> Таблица Tovar у меня является таблицей движения

А таблица OPERATION тогда у тебя что ?

И с какого перепугу они, эти две таблицы, друг на друга ссылаются ?

Рука руку моет ?)

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

> [63] Игорь Шевченко © (27.03.09 15:39)
Не всегда. Да и дешевле не значит лучше. Тоже конечно не всегда.
Но учиться то на чем то надо.
ИМХО склад и калькулятор каждый должен написать сам хотя бы раз. 8-)

Sergey13 © (27.03.09 16:00) [67]

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

> ИМХО склад и калькулятор каждый должен написать сам хотя
> бы раз. 8-)

Ни разу не писал. Пойду удавлюсь с горя :)

склад не писал. А вот калькулятор - да.
Поэтому убиваться об стену не буду, только напьюсь с горя -)

А я калькулятор не писал - мне убиться или упиться ? :)

по вкусу :) я бы упился :)

Утопиться, одним ударом по двум зайцам.

Ну а я не только не писал ни того, ни другого. Но и не разу не "фетчил". И уж тем более не "политурил"!
Так что мне всё по-фигу. :)

Дом "скорби"
Пациент с манией великого математика подходит к одному из своих соседей по палате:
- Я тебя сейчас продифференцирую !
Сосед падает в обморок. Подходит к другому:
- Я тебя сейчас продифференцирую !
Никакой реакции.
- Я тебя сейчас проинтегрирую !
Чувак забился в припадке.

"Математик" гордо озирается и, увидя в углу еще одного соседа, подходит к нему:
- Я тебя сейчас продифференцирую !
Никакой реакции.
- Я тебя сейчас проинтегрирую !
Никакой реакции.

- Ты чего не боишься !?
- А я е в степени х

← →
Xmen (2009-03-30 08:43) [75]

Ну вам спасибо хотя многое ругали и это полезно. Кое чему научился. Вернусь первой структуре базы, там мне многое было понятно а то сам спутался. Кое что стало ясно из ваших советов, это я об организации склада. Ну я еще вернусь за советами ;-)

Правильное сохранение при Мастер- Детаил Найти похожие ветки