|
|
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Мне кажется, что нужно завести три таблицы - Контрагенты , Поставщики , Потребители . В таблице Контрагенты отразить поля описывающие свойства контрагента, а в таблицах Поставщики и Потребители лишь по два поля - код поставщика (потребителя) и ссылку на код котрагента в таблице Контрагенты . Такая схема позволит "обслужить" ситуацию, когда один контрагент может выступать и в роли поставщика и в роли потребителя. Кроме того легко построить два VIEW, которые бы эмулировали две табицы (Поставщики и Потребители), но уже с полным набором полей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2008, 15:28:50 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
korda, Вот-вот. Я так пробовал, только не был уверен, что это "правильно" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2008, 15:40:40 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
guest_20040621Вы, простите, учитесь или работаете? Imho на профильных факультетах должны давать хотя бы основы, чтобы на практике не делать детских ошибок. Моя специальность никоим образом не связана ни с программированием, ни с СУБД в частности. guest_20040621Даже еще не открыв регламента, ясно, что должно быть сущность, идентифицирующая турнир. Что это за соревнования? Кто принимает в них участие? Кто обслуживает и организовывает эти соревнования? Где они проводятся? Да нет никаких соревнований. Я упростил пример, где статус участника может иметь значение, а может не иметь. В результатах матча - имеет, в турнирной таблице - нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2008, 15:54:56 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
> Моя специальность никоим образом не связана ни с программированием, ни с СУБД в частности. Значит, первое, что нужно сделать, - прочесть "Введение в системы баз данных" Дейта. Второе - осознать, что залог качества структуры данных - полная и правильная семантическая модель. Для вашего примера: ваша семантическая модель - "есть покупатели и продавцы", правильная семантическая модель - "есть субъекты предпринимательской деятельности [ограничения]". > Я упростил пример, где статус участника может иметь значение, а может не иметь. Думаю, вы уже поняли, что этот пример с предыдущим никак не связан. Следует заметить: избегайте нечетких многозначных атрибутов. "Статусом" может быть что угодно: от типа титульного спонсора до признака "команда дисквалифицирована". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2008, 19:35:09 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Cat2 пишет: > Похоже это ближе. А можно поподробней? > > > На мой взгляд роли контрагентов не нужны, Контрагент - одна из ролей. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2008, 19:48:47 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
ICQRobot пишет: > Обычно достаточно записывать приход со знаком плюс, а расход - со знаком > минус. > > Тогда, если количество в документе отрицательное, то в данном случае > контрагент выступает в роли покупателя[/quot] Т.е. принцып независимости бухучёта не для вас написан, да ? Одним документом проводим отгрузку и приёмку ? Ну-ну... Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2008, 19:50:41 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
korda пишет: > Мне кажется, что нужно завести три таблицы - *Контрагенты*, > *Поставщики*, *Потребители*. В таблице *Контрагенты* отразить поля > описывающие свойства контрагента, а в таблицах *Поставщики* и > *Потребители* лишь по два поля - код поставщика (потребителя) и ссылку > на код котрагента в таблице *Контрагенты*. Да нет. Надо сделать ОДНУ таблицу (ну или набор таблиц) субъектов хоздеятельности - физлиц и юрлиц. И ещё может что-то. Потом для каждого субъекта учета (который также может находится в этой таблице/таблицах) надо вести независимый список поставщиков и покупателей с их кодами - как ссылки в общую таблицу субъектов хоздеятельности. Возможны ещё какие-то роли, поэтому наверное стоит роль сделать универсальной, и использовать этот механизм в *Контрагентах*, *Поставщиках*, *Потребителелях* и ещё где угодно. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2008, 19:55:02 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
korda три таблицы - думаю многовато. Тут вся проблема в смене ролей от ситуации к ситуации. А вы жестко навешиваете ярлык поставщика или потребителя. А если мы с таким контрагентом бартер делать будем? Что тогда его в две таблицы записывать? Ведь сам тип операции уже скажет нам, в какой роли контрагент засветился. В свое время я решил этот вопрос с помощью двух таблиц. 1. Контрагенты. 2. Группы контрагентов. При этом каждый контрагент имеет ссылку на соответствующую группу. Группа показывает не жесткую принадлежность, а, скажем так, характерную роль того или иного контрагента. Группы добавляет не программист, а оператор, контрагентов можно перемещать из группы в группу при необходимости. Можно в таблице групп ввести внутреннюю ссылку для организации иерархического справочника групп в виде дерева. Опять же, реализовав такую структуру, вы перекладываете головную боль по организации данных на оператора и снимаете с себя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2008, 20:28:19 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
AndreiКrВедь сам тип операции уже скажет нам, в какой роли контрагент засветился. Логично. Однако, знать поставщик данный контрагент или потребитель необходимо заранее, до ввода данных в форму операции. Нужно же каким-то образом выдать пользователю список всех возможных поставщиков/потребителей? В "трехтабличной" модели хорошо ещё и то, что используются непосредственно возможности БД, по контролю целостности. Удаляем запись из таблицы Контрагенты , и получаем автоматическое удаление соответствующих записей из Поставщиков и Потребителей . Т.е., в какой-то мере вы получаете "бесплатный" менеджмент всех трех таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2008, 21:45:59 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
MasterZiv, кажется автор нигде не говорил, что его система является системой учета по нескольким предприятиям. Или я проглядел? С другой стороны, система, которая сегодня поддерживает учет по одному предприятию, завтра может переродиться в нечто более глобальное. Поэтому, почему-бы действительно не вести учет контрагентов не вообще, а с привязкой к конкретному предприятию, коих может быть несколько. Я просто пытаюсь выразить вашу идею более точно. Получается так - есть таблица Контрагенты , содержащая предприятия (для простоты не будем сейчас делить на физические и юридические лица), свои и чужие. Каждое предприятие может быть связано с другими поставщическими или потребительскими "узами". Рассмотрим только таблицу Поставщики, так как Потребители устроены анологично. В таблице Постащики два поля - поле - собственный код в таблице Контрагенты и код поставщика, опять-же из таблицы Контрагенты . Таблица Контрагенты : Код - Название - Адрес 1 - Автозавод - Москва 2 - Тепловозостроительный завод - Луганск 3 - Молокозавод - Ярославль Таблица Поставщики : "Свой" код - "Чужой" код 1 - 2 1 - 3 2 - 3 Т. е. поставщиками Автозавода являются Тепловозостроительный и Молокозавод Поставщиком Тепловозостроительного завода является Молокозавод. Таким образом, когда пользователю нужно будет оформить приход от лица Автозавода, то ему будет предложено выбрать из списка, в котором два элемента - Тепловозостроительный и Молокозавод. Такая схема ничуть не сложнее предложенной мной ранее, но "мощнее" тем, что поддерживает учет по нескольким конторам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2008, 22:18:12 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
На вашем месте, korda, я бы воздержался от публичных сообщений: ошибки нужно не тиражировать, а исправлять. Либо молча, либо с комментариями, что сделано неправильно. Опционально: прочтите хотя бы что-нибудь про основы проектирования. Можно из серии "для чайников". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2008, 22:26:23 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
AndreiКr, Как вы правильно заметели, кроме операций купли продажи могут иметь место и другие операции, поэтому схема приведенная выше может быть дополнена таблицей Операции . Таким образом в схему входят три таблицы - Контрагенты , Операции , Связи . Таблица Контрагенты : Код - Название - Адрес 1 - Автозавод - Москва 2 - Тепловозостроительный завод - Луганск 3 - Молокозавод - Ярославль ... Таблица Операции : Код - Название 1 - Поставка 2 - Приобретение 3 - Передача в собственность ... Таблица Связи : "Свой" код - "Чужой" код - Код операции 1 - 2 - 1 1 - 3 - 1 2 - 3 - 1 2 - 4 - 2 ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2008, 22:36:09 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
guest_20040621На вашем месте, korda, я бы воздержался от публичных сообщений: ошибки нужно не тиражировать, а исправлять. Либо молча, либо с комментариями, что сделано неправильно. Опционально: прочтите хотя бы что-нибудь про основы проектирования. Можно из серии "для чайников". В чем ошибка-то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2008, 22:49:20 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
korda пишет: > MasterZiv, кажется автор нигде не говорил, что его система является > системой учета по нескольким предприятиям. Или я проглядел? Не говорил. Это я говорю. сегодня она не является, завтра - будет являться. Требования меняются. > С другой стороны, система, которая сегодня поддерживает учет по одному > предприятию, завтра может переродиться в нечто более глобальное. > Поэтому, почему-бы действительно не вести учет контрагентов не вообще, а > с привязкой к конкретному предприятию, коих может быть несколько. Я > просто пытаюсь выразить вашу идею более точно. А, ну спасибо. Я как всегда сначала написал, потом прочитал. :-)) > Рассмотрим только таблицу *Поставщики,* так как *Потребители* устроены > анологично. В таблице *Постащики* два поля - поле - собственный код в > таблице *Контрагенты* и код поставщика, опять-же из таблицы *Контрагенты*. > Одна таблица должна быть. И три поля должно быть в ней. > Таблица *Контрагенты*: > > Код - Название - Адрес > 1 - Автозавод - Москва > 2 - Тепловозостроительный завод - Луганск > 3 - Молокозавод - Ярославль > > Таблица *Поставщики*: > > "Свой" код - "Чужой" код > 1 - 2 > 1 - 3 > 2 - 3 Нет. Таблица РОЛИ-КОНТРАГЕНТОВ: код субъекта ХД - Код роли - код контрагента 1 - Поставщик - 2 1 - Поставщик - 3 1 - Покупатель - 3 2 - Поставщик - 3 > Такая схема ничуть не сложнее предложенной мной ранее, но "мощнее" тем, > что поддерживает учет по нескольким конторам. Тут как бы главное - понять, что в таблицах лежат ДАННЫЕ. Если по составу записи данные одинаковые, это должна быть ОДНА таблица. Мысль главная в этом. А что у поставщиков и покупателей данные одинаковые, это достаточно очевидно. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2008, 01:02:14 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
korda пишет: > Таблица *Связи*: > > "Свой" код - "Чужой" код - Код операции > 1 - 2 - 1 > 1 - 3 - 1 > 2 - 3 - 1 > 2 - 4 - 2 > ... А, ну вот, вы и сами знали. :-) А на счёт ошибок я тоже не понял нифига. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2008, 01:03:43 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
> В чем ошибка-то? Это не одна ошибка. Это куча ошибок, основную не выделить. Пожалуй, наиболее существенная в данном случае - методологическая. Вы полагаете возможным явное описание атрибутов неявных процессов. Также существенной ошибкой следует считать кривой костыль вместо решения типовой задачи контроля доступа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2008, 02:21:07 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
guest_20040621> В чем ошибка-то? Это не одна ошибка. Это куча ошибок, основную не выделить. Спасибо, я понял! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2008, 09:06:31 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Michael_NNickChay ... Схема данных. Таблица Участники. 1. Код. 2. Наименование. Таблица Матчи: Код матча. Код хозяина. Код гостя. Мячи хозяина. Мячи гостя. Все.Вместе с 1-й таблицей это даст полную информацию по задаче. +1 И нечего заморачиваться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2008, 13:12:12 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
> И нечего заморачиваться Одноразовыми должны быть презервативы, а не структуры данных. Стадион может быть дисквалифицирован. Матч может быть перенесен. Матч может быть переигран. Мячи забивают игроки. Которые имеют возможность менять команду по ходу турнира. И т. д. Единственный вариант проектирования структуры данных для спортивных состязаний (любых) - регламент этих состязаний: это практически готовая семантическая модель. Здесь нечего обсуждать, это нужно просто запомнить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2008, 16:31:16 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
guest_20040621Одноразовыми должны быть презервативы, а не структуры данных. Стадион может быть дисквалифицирован. Матч может быть перенесен. Матч может быть переигран. Мячи забивают игроки. Которые имеют возможность менять команду по ходу турнира. И т. д. Единственный вариант проектирования структуры данных для спортивных состязаний (любых) - регламент этих состязаний: это практически готовая семантическая модель. Здесь нечего обсуждать, это нужно просто запомнить Простите уважаемый, какую задачу решаем? Все, которые могут когда-либо возникнуть? Уверены, что все учли? А изменение регламента не учитывали? Предлагаю не изобретать мегауниверсальную структуру, а решить поставленную задачу. Появятся новые требования - на новой итерации внесем изменения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2008, 08:01:12 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
> Простите уважаемый, какую задачу решаем? Я - никакой. Просто рассказал, как эту задачу нужно решать. > А изменение регламента не учитывали? Хороший вопрос. Заметили ремарку про явные атрибуты неявных процессов? Разжевывать надо? > Предлагаю не изобретать мегауниверсальную структуру, а решить поставленную задачу. Задача имеет одно решение. Я о нем сказал. Любые другие варианты - бессовестный отъем бабла у заказчика. > Появятся новые требования - на новой итерации внесем изменения. Дружище, не надо дискредитировать профессию. Не умеете проектировать - займитесь чем-нибудь попроще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2008, 19:07:09 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
guest_20040621Также существенной ошибкой следует считать кривой костыль вместо решения типовой задачи контроля доступа. Я бы назвал это основной ошибкой при проектировании "контрагентов" и их "ролей". Кроме "ролей", которые лежат на поверхности, могут быть "роли" свосем другого "масштаба ответствнности", например, банки. Равно как у этих "ролей" будут собственные атрибуты, например, политика поставки у поставщика, политика кредитования в банке. AndreiКrkorda три таблицы - думаю многовато. Тут вся проблема в смене ролей от ситуации к ситуации. А вы жестко навешиваете ярлык поставщика или потребителя. А если мы с таким контрагентом бартер делать будем? Что тогда его в две таблицы записывать? Ведь сам тип операции уже скажет нам, в какой роли контрагент засветился Я Вас наверное огорчу, но даже 3-х таблиц для реальной эксплуатации будет мягко говоря мало. И еще. Роли не меняются, они либо включаются, либо блокируются, каждая независимо. Формально, необходимо иметь возможность определить способности некоторого субъекта обладать определенной ролью. Причем этот контроль не может быть одноуровневый (так что операции будут вторичны), если ДО того, как субъект фактически будет обладать определенной ролью, необходимо решить вопрос, возможно ли это в принципе (визирование). Сравните, закупить у ООО "Рога и Копыта" 100 авторучек или открыть счет в АКБ "Рога и Копыта" (пусть даже положи туда стоимость этих самых 100 авторучек). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 10:59:43 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Сергей Васкецов Я Вас наверное огорчу, но даже 3-х таблиц для реальной эксплуатации будет мягко говоря мало. Да, для реальной ситуации 3-х таблиц мало. Сергей Васкецов И еще. Роли не меняются, они либо включаются, либо блокируются, каждая независимо. Формально, необходимо иметь возможность определить способности некоторого субъекта обладать определенной ролью. Причем этот контроль не может быть одноуровневый (так что операции будут вторичны), если ДО того, как субъект фактически будет обладать определенной ролью, необходимо решить вопрос, возможно ли это в принципе (визирование). Сравните, закупить у ООО "Рога и Копыта" 100 авторучек или открыть счет в АКБ "Рога и Копыта" (пусть даже положи туда стоимость этих самых 100 авторучек). Раз пять перечитал, но вроде понял. Может быть, может быть... Но как-то слишком сложно... Вы учтите, что человек, задавший вопрос только учится проектировать БД, а чтобы их проектировать хорошо, нужно спроектировать не одну. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 21:37:04 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
На каждый вопрос могут быть даны несколько ответов, и трудно определить, правильные они или нет, если не имеется для этого четких критериев. Трех таблиц может быть достаточно, если задача - написать контрольную в институте. Понимаете, к чему я клоню?... Мы можем начать учитывать различные аспекты и не закончим обсуждение никогда. Да и не знаем мы всех факторов, так как получили вопрос из двух строчек, а не глубоко проработанное ТЗ. Да и никто не требует от нас учитывать ВСЁ, начиная от быстродействия и использования дискового пространства, до возможных проблем с будущей репликацией или безопасностью. Но знаете что? Читать ответы и те, простые, "одноаспектные" и более развернутые, - философские ужасно интересно, так как и в тех и в других есть "своя правда". Единственное, чего бы хотелось пожелать пишущим философские посты, - это не ограничиваться несколькими фразами типа: это всё чушь, идите читайте книжки, а расскрывать свои мысли чуть более полно, вы же хотите, чтобы вас понимали?)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 23:03:48 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
> На каждый вопрос могут быть даны несколько ответов, и трудно определить, правильные они или нет, если не имеется для > этого четких критериев. Логично. Также логично уточнять граничные условия при формулировании вопроса. ;) > не ограничиваться несколькими фразами типа: это всё чушь, идите читайте книжки, а расскрывать свои мысли чуть более > полно, вы же хотите, чтобы вас понимали? Ну вот смотрите: в этом обсуждении раз сто было сказано: проектирование структуры данных для соревнований - только посредством регламента. И что? Соседний тред - хочу базу данных для футбольной статистики. "Физики и юрики" - тема уже в асфальт утоптана. Соседний тред - помогите найти решение для структуры. Бесполезно писать о чем-то подробно, возможны только самые простые паттерны (и это, кстати, тоже обсуждалось). Imho достаточно показать автору, что существуют другие точки зрения, - найти нужный материал сейчас очень просто, было бы желание. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 01:23:15 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35642037&tid=1543488]: |
0ms |
get settings: |
10ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
190ms |
get topic data: |
13ms |
get forum data: |
6ms |
get page messages: |
72ms |
get tp. blocked users: |
1ms |
| others: | 237ms |
| total: | 555ms |

| 0 / 0 |
