ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Архитектурное решение
12 сообщений из 12, страница 1 из 1
Архитектурное решение
    #39453843
chipakunos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chipakunos
Гость
Есть таблица со списком компаний
...
Рейтинг: 0 / 0
16.05.2017, 14:32
| Ответить | Цитировать | Написать  
Архитектурное решение
    #39453854
chipakunos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chipakunos
Гость
Есть таблица со списком компаний
Код: sql
1.
2.
3.
4.
5.
6.
CREATE TABLE public.company
(
  id integer NOT NULL DEFAULT nextval('company_id_seq'::regclass),
  full_name character(100),
  short_name character(30),
)



Каждая компания может быть пиром другой компании. Как правильно это спроэктировать?
Думал про следующий вариант:
Код: sql
1.
2.
3.
4.
5.
CREATE TABLE public.peers
(
  id_copmany_one FK company(id)
  id_copmany_two FK company(id)
)


Но тогда возникает проблема отображения инфы. Если я хочу посмореть пиров компании А, то тогда мне придется делать два запроса, ибо компания А, можеть быть и в id_copmany_one, и в id_copmany_two. Терятся много времени на выполнение запроса и обработку на результата на стороне клиента (предварительные предположения).
Может есть у кого-то другие, более адекватные идеи.
P.S.
Задача - вбить short_name компании и получить всех её пиров. Желательно решение в 3НФ.
...
Рейтинг: 0 / 0
16.05.2017, 14:42
| Ответить | Цитировать | Написать  
Архитектурное решение
    #39453859
chipakunos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chipakunos
Гость
Создавать для каждой компании список своих пиров мне кажется неэфективным так как не гарантируется целостность данных.
...
Рейтинг: 0 / 0
16.05.2017, 14:45
| Ответить | Цитировать | Написать  
Архитектурное решение
    #39453876
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
chipakunos,

а по русски всё то же самое можешь ?


если нет -- то попробуй математически точно, скольконаправленный граф , например, как на нем с петлями, и т.п. особостями
Или всё ограничено обычным деревом ?

если не фтыкаешь -- прочитай букварь https://ru.wikipedia.org/wiki/Дерево_(теория_графов)

а то "пир" по русски -- это пафосный коллективный обряд насыщения и пития.
...
Рейтинг: 0 / 0
16.05.2017, 15:02
| Ответить | Цитировать | Написать  
Архитектурное решение
    #39453878
Ы2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ы2
Участник
chipakunos…Если я хочу посмореть пиров компании А, то тогда мне придется делать два запроса , ибо компания А, можеть быть и в id_copmany_one, и в id_copmany_two.
Почему два? Если не думать, а делать тупо, можно, напр., поступить так:
Код: sql
1.
2.
3.
select id_copmany_one, id_copmany_two from peers where id_copmany_one = 1
union
select id_copmany_two, id_copmany_one from peers where id_copmany_two = 1;
...
Рейтинг: 0 / 0
16.05.2017, 15:05
| Ответить | Цитировать | Написать  
Архитектурное решение
    #39453882
chipakunos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chipakunos
Гость
Ы2, ну, именно этот запрос я и имел ввиду. Именно такое решение мне кажется не эфективным и прямолинейным.
...
Рейтинг: 0 / 0
16.05.2017, 15:12
| Ответить | Цитировать | Написать  
Архитектурное решение
    #39453915
chipakunos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chipakunos
Гость
qwwq,

прошу прощения за слэнг, невнимательность с моей стороны. Под пирами подразумивается компании, которые между собой похожи.
Над постановкой задачи в математической форме работаю.
...
Рейтинг: 0 / 0
16.05.2017, 15:45
| Ответить | Цитировать | Написать  
Архитектурное решение
    #39453947
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
chipakunos,

как я понял, вас интересует двунаправленные ("равноправные") связи (если А -"пир" И <=> то Б - "пир" А)
но корткие -- т.е. без наследования (из [А пир Б и Б пир С] не следует что [А пир С])

//если все не так , то дальнейшее не к вам.

тогда запись в виде таблицы связей с 2-мя узлами и ограничением ид_Узла_1>ид_узла_2 (чтобы не повторяться) вас вполне устроит.

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

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

мне лично юнионы кажутся более естественными. как автогарантия связи 2-х и только 2-х узлов каждой "связью".
...
Рейтинг: 0 / 0
16.05.2017, 16:13
| Ответить | Цитировать | Написать  
Архитектурное решение
    #39453950
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
qwwqchipakunos,

как я понял, вас интересует двунаправленные ("равноправные") связи (если А -"пир" Б <=> то Б - "пир" А)
но корткие -- т.е. без наследования (из [А пир Б и Б пир С] не следует что [А пир С])

//если все не так , то дальнейшее не к вам.

тогда запись в виде таблицы связей с 2-мя узлами и ограничением ид_Узла_1>ид_узла_2 (чтобы не повторяться) вас вполне устроит.

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

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

мне лично юнионы кажутся более естественными. как автогарантия связи 2-х и только 2-х узлов каждой "связью".
поправил
...
Рейтинг: 0 / 0
16.05.2017, 16:16
| Ответить | Цитировать | Написать  
Архитектурное решение
    #39453992
Ы2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ы2
Участник
chipakunosЫ2, ну, именно этот запрос я и имел ввиду. Именно такое решение мне кажется не эфективным и прямолинейным.
Это один запрос, выполняемый на сервере, что обычно эффективнее утягивания массы данных для обработки на клиенте. Прямолинейность же вообще не критерий.
...
Рейтинг: 0 / 0
16.05.2017, 17:12
| Ответить | Цитировать | Написать  
Архитектурное решение
    #39454741
chipakunos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chipakunos
Гость
Ы2,

Спасибо за ответы, просто у меня есть постоянно некое недоверие к своим решениям. Вот и уточняю здесь.
...
Рейтинг: 0 / 0
17.05.2017, 15:08
| Ответить | Цитировать | Написать  
Архитектурное решение
    #39454755
chipakunos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chipakunos
Гость
qwwq,

абсолютно точно поняли задачу. Спасибо за обширный ответ.
...
Рейтинг: 0 / 0
17.05.2017, 15:15
| Ответить | Цитировать | Написать  
12 сообщений из 12, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Архитектурное решение
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&fpage=73&tid=1996510]:
 0ms
get settings:
 9ms
get forum list:
 12ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 35ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 58ms
get tp. blocked users:
 2ms
others: 15ms
total:  155ms
созд. / загр.: 155ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]