
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
22.10.2014, 13:39:19
|
|||
|---|---|---|---|
|
|||
PostgreSQL выбор ключа - простой или составной |
|||
|
#18+
Добрый день. В БД (PostgreSQL) предполагается хранить информацию об организациях. Все организации имеют одинаковую четырехуровневую структуру. Наименование каждого уровня при этом в разных организациях различны. Предполагается делать 5 соответствующих таблиц Таблица организаций: id (primary key) -- название организации Таблица уровня один: id (primary key) -- id организации (foreign key) -- название уровня один Таблица уровня два: id (primary key) -- id уровня один (foreign key) -- название уровня два и т.д. Предполагаем, что количество таких организаций может вырасти и исчисляться миллионами. Вопрос: каким делать ключ в таблицах соответствующих уровней - простым или составным. т.е. так, как структура описана сейчас или Таблица уровня один id (primary key) -- id организации (primary key) -- название уровня один Таблица уровня два id (primary key) -- id уровня один (primary key) -- название уровня два и т.д. Иными словами id каждого уровня следует делать в принципе уникальным или уникальным в рамках соответствующего родительского уровня (организации)? Основная масса запросов будет на чтение. Пожалуйста, посоветуйте, как лучше выбрать ключ и почему. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.10.2014, 15:04:00
|
|||
|---|---|---|---|
|
|||
PostgreSQL выбор ключа - простой или составной |
|||
|
#18+
Во-первых, чисто технически на земном шаре не наберётся такое количество организаций. Во-вторых, лично я бы хранил всё в одной таблице, используя денормализованный строковый первичный ключ типа такого: КлючНазваниеabcdefghijkГлавная организацияabcdefghijk_00001подорганизация уровня 1abcdefghijk_21421_12342подорганизация уровня 2abcdefghijk_1234a_bbbgs_asdgg_00000подорганизация уровня 4 Такая структура сильно упрощает выборки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.10.2014, 15:22:27
|
|||
|---|---|---|---|
|
|||
PostgreSQL выбор ключа - простой или составной |
|||
|
#18+
Dimitry Sibiryakov, спасибо за ответ. Термин "организация" использовал лишь для наглядности описания ситуации. В целом - это просто некоторая сущность, которая имеет подуровни. И в целом могут добавиться новые. На каждом подуровне может быть много объектов этого подуровня (т.е. на описанном примере у каждой организации может быть 1000 разных департаментов с разными названиями (в смысле названия департаментов в разных организациях отличаются), внутри департамента 1000 разных отделов и т.д.) При это важно знать, какой департамент какой организации соответствует. Т.е. всегда нужно иметь возможность установить связь между объектом уровня и его родительским уровнем (в какой организации находится данный департамент, в каком департаменте находится данный одел и т.д.). Ну и наоборот: какие департаменты есть в организации, какие отделы есть в департаменте и т.д. Предложенное вами решение понял. Единственный вопрос - какие преимущества такого подхода? Запросы будут выполняться быстрее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.10.2014, 15:46:19
|
|||
|---|---|---|---|
|
|||
PostgreSQL выбор ключа - простой или составной |
|||
|
#18+
Lilu_17, в 9.4 можно полноценно работать с json(b), так что если вас устраивает парадигма nosql, то можете не мучаться а сделать структуру типа id.org.level.name ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.10.2014, 16:53:23
|
|||
|---|---|---|---|
|
|||
PostgreSQL выбор ключа - простой или составной |
|||
|
#18+
Oleg Bartunov, спасибо. Да, действительно можно поступить и так. Если бы было возможно, то вообще бы использовали redis в качестве БД, однако по ряду причин выбран PostgreSQL. Я не уверен, что большой JSON - это оптимальный путь для PostgreSQL в плане быстроты поиска. Предполагается, что объектов на каждом уровне может быть много, у объектов могут быть прочие свойства, т.е. не хочется вдруг однажды попасть под ограничения размера поля в 1ГБ (совсем не уверен, что это случится, но все же). Правда, должен признать, быстро погуглив, я не нашел сразу подтверждений тому, что большой JSON замедлит поиск. Более понятной и удобной мне кажется идея вынесения каждого уровня в отдельную таблицу. И я не вижу пока в чем тут может быть проблема. Единственный вопрос - как лучше выбрать ключ с точки зрения быстроты поиска. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.10.2014, 14:55:25
|
|||
|---|---|---|---|
|
|||
PostgreSQL выбор ключа - простой или составной |
|||
|
#18+
Dimitry Sibiryakov…я бы хранил всё в одной таблице, используя денормализованный строковый первичный ключ типа такого: КлючНазваниеabcdefghijkГлавная организацияabcdefghijk_00001подорганизация уровня 1abcdefghijk_21421_12342подорганизация уровня 2abcdefghijk_1234a_bbbgs_asdgg_00000подорганизация уровня 4 Такая структура сильно упрощает выборки. Думается, этот ключ лучше делать на ltree. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.10.2014, 16:35:25
|
|||
|---|---|---|---|
|
|||
PostgreSQL выбор ключа - простой или составной |
|||
|
#18+
Lilu_17Добрый день. Иными словами id каждого уровня следует делать в принципе уникальным или уникальным в рамках соответствующего родительского уровня (организации)? в принципе уникальным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.10.2014, 16:36:59
|
|||
|---|---|---|---|
|
|||
PostgreSQL выбор ключа - простой или составной |
|||
|
#18+
Dimitry SibiryakovВо-первых, чисто технически на земном шаре не наберётся такое количество организаций. Во-вторых, лично я бы хранил всё в одной таблице, используя денормализованный строковый первичный ключ типа такого: КлючНазваниеabcdefghijkГлавная организацияabcdefghijk_00001подорганизация уровня 1abcdefghijk_21421_12342подорганизация уровня 2abcdefghijk_1234a_bbbgs_asdgg_00000подорганизация уровня 4 Такая структура сильно упрощает выборки. фигасебе упрощает. поискать в 4-м уровне, выбрать все главные, посчитать сколько у нас 3-х.... все это усложняется, а не упрощается ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.10.2014, 08:32:32
|
|||
|---|---|---|---|
PostgreSQL выбор ключа - простой или составной |
|||
|
#18+
Lilu_17, А почему Вас не устраивает обычное двоичное дерево, то есть parent - children В виде списка смежных вершин (Adjacency List) Если захотите ускорить поиск, то в виде вложенных множеств Nested Sets, но Вам видимо это не понадобиться, так как у Вас маленькая глубина ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/search_topic.php?author=ARST&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
5ms |
get forum list: |
11ms |
get settings: |
7ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
175ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 450ms |
| total: | 701ms |

| 0 / 0 |
