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

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

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

Алгорит записей в БД накладных... [D7, MySQL]

Страницы: 1 2 >
Сергей © (2008-09-21 21:56:00)
Доброго времени суток.
Подскажите пожалуйста логику создания базы данных для хранения например накладных. В моем понимании таблица имеет определенные столбцы. И вот никак не могу понять как создать таблицу которая будет содержать: Номер накладной, отправителя, получателя и самое главное список позиций наклодной с ценами количеством и тд. Ведь заранее не известно сколько позиций в каждой накладной и тд. неужели придется создавать для каждого перечня отдельные таблицы!?
Если возможно примерчик в синтаксиск MySQL.
Заранее спасибо.
p.s. Я только начинаю вникать в базы данных и прошу не судить строго.

Юрий Зотов (2008-09-23 11:30:00) [1]
> MsGuns © (22.09.08 22:36) [15]

> В целом набор инструкций для какого-то "студенческий" проекта.

Даже еще хуже. Это вообще НЕ руководство к действию, а всего лишь ОЧЕНЬ сильно упрощенный пример построения БД, на котором показана ЛОГИКА проектирования. И не более.

"Сильно упрощенный" - специально. Чтобы "лес не был заслонен деревьями". Чтобы автор мог этот пример понять. Потому что, если у человека возникла проблема с реализацией отношения "многие ко многим" (да даже и сам этот термин ему, похоже, еще незнаком), то именно такие примеры ему пока что и нужны. Потому что в реальных он просто утонет.

Так что - благодарю за критику, но... LOL!
:o)

Рамиль (2008-09-23 09:30:00) [2]

> Первый шаг уже сделал правдо коряво, но все-таки... этикетки
> на продукцию мы теперь через FastReport + база изделий в
> файле, печатаем (раньше в эксель)
>
> p.s. Не судите строго...

Ну так вот, почитай немного, окупится в будущем, тем что не будет коряво.

Sergey13 (2008-09-23 09:15:00) [3]
> [24] MsGuns © (23.09.08 09:09)

В Екселе задачи решать тоже надо уметь и сам он их не решает, если они сложнее чем 2+2.
Накидав батонов можно получить достаточно жизнеспособный продукт "для внутреннего потребления".
Никто еще наверное не начинал писать с системы уровня ERP, готовой к массовому распространению за огромные деньги через полтора месяца после начала писания.

MsGuns (2008-09-23 09:09:00) [4]
>Sergey13 © (23.09.08 08:54) [23]

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

Sergey13 (2008-09-23 08:54:00) [5]
> [18] MsGuns © (22.09.08 23:02)
> [19] MsGuns © (22.09.08 23:06)

ИМХО, ты сильно перегнул. По твоей логике самыми лучшими базовиками должны быть бухгалтеры, потому тчо они про учет все знают. Программист тем и отличается от профильного специалиста(а он должен быть!!!), что может (должен мочь) из его разговоров построить модель, которую можно реализовать доступными программисту методами. А для этого нужно представлять себе теорию СУ[Р]БД. Именно она первична, а не предметная область.
ИМХО все исключительно.

Сергей (2008-09-22 23:19:00) [6]
MsGuns, MySQL мне с ним по проще разобраться... да и удаление у нас некоторое есть... поэтому хочется базу хранить в инете. MS - денег стоит.

Сергей (2008-09-22 23:17:00) [7]
MsGuns извиняюсь за "пургу" но по другому пока не получается.

Делфи: Хобби недалекой юнности.
Цель: Немного облегчить себе жизнь на работе.
Надоело в экселе и на бумажке вести расчеты и учет.
Объект: маааленькое производство мебели, приходится быть всем начиная от
конструктора заканчивая грузчиком.

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

p.s. Не судите строго...

MsGuns (2008-09-22 23:10:00) [8]
И последнее.
MySQL далеко не самый лучший сервер для задач подобного класса - ИМХО, стОит посмотреть в сторону более промышленных (IB/FB, MS SQL...)

MsGuns (2008-09-22 23:06:00) [9]
По поводу правильности ведения материального учета - см.книги не по программированию, а по бухгалтерскому учету - там все написано ясно, на русском, и нету всяких тарабарских заклинаний типа "сервер", "эскюэль" и т.д. ;)))

MsGuns (2008-09-22 23:02:00) [10]
>Сергей (22.09.08 22:53) [17]
>MsGuns конкурировать с 1С я не собираюсь

Вы побаловаться решили, да ? А если нет, то изучите сначала предметную область. Без этого не стОит вообще садиться за проектирование. Зачем строить дом, изначально ни к чему не пригодный - просто угробить материалы ?

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

Как я могу давать советы не зная ЧТО нужно сделать ? Лучше всего Вам побеседовать с гл.бухгалтером и выяснить у него, что он хочет. После этого очень рекомендую ознакомиться с уже существующими решениями, например, так пугающей Вас 1С, которая, кстати, в базовой конфигурации содержит очень много весьма полезной информации - по крайней мере ознакомившись детально с документами 1С, Вы не будете писать такую пургу в сабже

Сергей (2008-09-22 22:53:00) [11]
MsGuns конкурировать с 1С я не собираюсь, инструкций для "Студенческого проекта" вполне достаточно, вникать в складской или бухгалтерский учет пока не требуется. Вы слишком углубились, а всего лишь требовалась логика построения БД.

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

MsGuns (2008-09-22 22:44:00) [12]
В целом по сабжу.
Автор, похоже, элементарно не знает ЧТО нужно сделать, по крайней мере не может внятно сформулировать. Материальный учет можно (и нужно) реализовывать по-разному. Например, модель учета стройматериалов или материалов в производстве весьма отличается от учета товаров, а учет препаратов в фармации разнИтся от учета кондитерки или бакалеи (хоть и то, и другое - торговля). Малоценка вообще реализуется просто. Кроме того, есть учет складской, есть бухгалтерский и это тоже две большие разницы.

Так что налицо типичная ошибка новичка - еще не знаем куда поедем, и поедем ли вообще, а идем в магазин и выбираем велосипед. А может вообще лодка надувная понадобится ? Или дельтаплан ?

MsGuns (2008-09-22 22:36:00) [13]
>Юрий Зотов © (22.09.08 02:00) [8]
>Таблица 1 "Служащие"

В документах на перемещение ТМЦ если и нужен, то лишь для выдачи (списания) в подотчет. В остальных случаях - фтопку !

>Таблица 2 "Товары"

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

>Таблица 3 "Цены" (т.к. цены могут меняться)

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

>Таблица 4 "Накладные" (хранит "шапки" всех накладных)
>ID_отправителя (ссылка на таблицу 1) ID_получателя (ссылка на таблицу

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

>Юрий Зотов © (22.09.08 02:02) [9]
>Добавление: в таблице 5 поля "Номер накладной" и "товар" образуют составной первичный ключ.

А вот этого делать ктегорически нельзя !

В целом набор инструкций для какого-то "студенческий" проекта. Извини за прямоту, но это так ;)

Сергей (2008-09-22 22:20:00) [14]
Юрий Зотов огромное спасибо за исчерпывающий ответ, расставили все по полочкам, это именно то, что мне было и нужно!

Стоит все-таки почитать теорию БД.

Petr V. Abramov спасибо за ссылку, попытаюсь осилить 1000 страничный труд, но все-таки ответ Юрия мне кажется, сократил чтение страниц на 200 точно =)

sniknik (2008-09-22 09:01:00) [15]
> Одна и та же накладная может содержать несколько товаров.
и даже несколько позиций одного и того же товара. у нас было, просили так сделать т.к. весы больше 1000кг не "поднимают", а отгружать проще "партиями" по 1-й завеске, чем все в кучу, оно так и занимает 1 место в машине и принимается/проверяется в магазинах тоже так же, частями.

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

Palladin (2008-09-22 02:55:00) [16]
без осознания теории отношений можешь забыть о своих накладных

Юрий Зотов (2008-09-22 02:16:00) [17]
> Сергей (21.09.08 21:56)

> заранее не известно сколько позиций в каждой накладной и тд. неужели
> придется создавать для каждого перечня отдельные таблицы!?

Один и тот же товар может упоминаться в нескольких накладных.
Одна и та же накладная может содержать несколько товаров.

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

В нашем случае это таблица 5. Она реализует связку "многие ко многим" между таблицами 4 и 2.

Германн (2008-09-22 02:15:00) [18]
"Как пройти в библиотеку?
В два часа ночи!
Идиот!"
(с)

Юрий Зотов (2008-09-22 02:02:00) [19]
Добавление: в таблице 5 поля "Номер накладной" и "товар" образуют составной первичный ключ.

Юрий Зотов (2008-09-22 02:00:00) [20]
> Сергей (21.09.08 21:56)

Таблица 1 "Служащие"
Поля: ID (ключ), ФИО, Другие (если надо)

Таблица 2 "Товары"
Поля: ID (ключ), Наименование, Другие (если надо).

Таблица 3 "Цены" (т.к. цены могут меняться)
Поля: ID (ключ), ID_товара (ссылка на таблицу 2), Цена, Дата, Другие (если надо).

Таблица 4 "Накладные" (хранит "шапки" всех накладных)
Поля: Номер (ключ ), ID_отправителя (ссылка на таблицу 1),
ID_получателя (ссылка на таблицу 1), Дата, Другие (если надо).

Таблица 5 "Позиции накладных" (хранит все позиции всех накладных)
Поля: Номер накладной (ссылка на таблицу 4), товар (ссылка на таблицу 2), Количество, Другие (если надо).

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

Наверх

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