|
|
|
как лучше реализовать и хранить доп параметры в очень большом справочнике
|
|||
|---|---|---|---|
|
#18+
в справочнике организаций может быть докучи различных доп параметров по каждой организации необходимо придумать механизм как лучше их хранить доп параметры причем эти параметры могут быть разных типов даннных от простого числа, до больших текстов предполагаю создать отдельную таблицу для описания типов доп параметров (1 Телефон Строка10; 2 урл Строка255, дата поставки на учет и тд) как лучше хранить значения доп параметров? json, xml, что бы быстро работала выгрузка данных по очень большому спискку организаций? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 10:47 |
|
||
|
как лучше реализовать и хранить доп параметры в очень большом справочнике
|
|||
|---|---|---|---|
|
#18+
Legushka, Тут надо смотреть (тестировать при нагррузке) на то, что у вас есть и что вам лучше подойдёт. Если у вас кол-во доп-параметров ограничено, то можно для каждого завести отдельную колонку в доп-таблице, как вы и предложили. Правда, вместо “Строка10” или “Строка255” я бы использовал просто `text`. Я так хранил ISO8583 транзакции в своё время. Если диапазон возможных параметров открыт, то: использовать неструктурированные типы: hstore, xml, jsonb (индексируются GiST + GIN) использовать EAV (Entity-Attribute-Value) модель. Тема холиворная, я просто упоминаю возможность. EAV сваливает в кучу все параметры и их типы (`text` для всех), и это есть плохо, т.к. нет возможности проверять вставляемые значения на корректность. Также индексы будут возращать данные в иной последовательности, ибо текст. Как вариант предлагается сделать несколько вспомогательных EAV таблиц, по таблице для каждого из используемых типов данных. С типизацией и индексами будет лучше, но проверять наличие параметра станет сложнее -- надо будет залезть в несколько таблиц. Можно представление на доп-таблицы повесить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 11:25 |
|
||
|
как лучше реализовать и хранить доп параметры в очень большом справочнике
|
|||
|---|---|---|---|
|
#18+
vyegorovМожно представление на доп-таблицы повесить. по поводу представления тут есть одна сложность: представление на момент его создания должна знать сколько колонок в итоге вернуть надо, не получится сделать в таком виде как select * from... можно правда после каждого добавления нового типа параметра переписывать представление попробую использовать неструктурированные типы (накатаю пилотный вариант, посмотрю как работает по скорости) спасибо за подсказки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 11:44 |
|
||
|
как лучше реализовать и хранить доп параметры в очень большом справочнике
|
|||
|---|---|---|---|
|
#18+
Legushkaпо поводу представления тут есть одна сложность: представление на момент его создания должна знать сколько колонок в итоге вернуть надо, не получится сделать в таком виде как select * from... EAV модель подразумевает, что колонок всего 3: ID объекта, имя параметра, значение параметра. Все параметры для объекта хранятся в виде набора строк. И да, искать объекты, у которых обязательно присутствуют, скажем, 3 параметра становиться очень заковыристо, т.к. `IN ()` тут не поможет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 11:48 |
|
||
|
как лучше реализовать и хранить доп параметры в очень большом справочнике
|
|||
|---|---|---|---|
|
#18+
vyegorovLegushkaпо поводу представления тут есть одна сложность: представление на момент его создания должна знать сколько колонок в итоге вернуть надо, не получится сделать в таком виде как select * from... EAV модель подразумевает, что колонок всего 3: ID объекта, имя параметра, значение параметра. Все параметры для объекта хранятся в виде набора строк. И да, искать объекты, у которых обязательно присутствуют, скажем, 3 параметра становиться очень заковыристо, т.к. `IN ()` тут не поможет.3 экзистса -- не проблема. проблема (относительная) -- что в общем случае имеем поиск по плавающему числу вхождений, -- т.е. плавающему числу эксизстсов -- т.е. динамический скл. вариант со сворачиванием еав--вхождений ключей|самих значений в массив предлагалсо? [либо "матвью" агрегата таблицы атрибутов, либо единственно--присутствующей таблицы атрибутов именно в свернутом состоянии] там индексы поинтереснее можно наворотить, со всеми этими && &> <& и прочими массивными удобствами. то же -- в терминах массива тегов -- искать по "tag". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 12:16 |
|
||
|
как лучше реализовать и хранить доп параметры в очень большом справочнике
|
|||
|---|---|---|---|
|
#18+
Советую вам максимально зафиксировать уже известные аттрибуты в соотв таблицы, типа: Организации (реквизиты контрагента) ---Адреса (Юридический. фактический, почтовый и т.д. желательно разобранные по кладру) ---Контакты(Тип, значение, дата начала, дата окончания) ---Регистрац док-ты (ИНН/КПП, ОГРН, лицензии, разрешения и т.д.)(Вкл Наимен, номер, серию, дату, орган, дату окончания и т.д.) ---Виды деятельности (список кодов ОКВЭД) ---Коды статистики (ОКПО, ОКОПФ, ОКФС, ОКОГУ и т.д. с датой начала и окончания) ---Органы управления (ген.дир., глав бух и т.д.) ---Доверенные лица (№ доверенности, дата, окончание и т.д.) ---Учредители ---Конечные бенефициары ---Счета в банках (БИК, номер счета) ---Доп параметры (EAV(Код, значение, дата начала, дата окончания)) И думаю не будет страшно в основной таблице предусмотреть поле jsonb или xml ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 15:02 |
|
||
|
как лучше реализовать и хранить доп параметры в очень большом справочнике
|
|||
|---|---|---|---|
|
#18+
Сергей В., таблица Организация приведена как пример, реальный случай связан с другой таблицей где туева куча полей обязательных, дальше было решено использовать поле типа hstory, но за определенное время и этот сборник стал очень большой. я недавно на этом проекте и уже ждут решений по ускорению и упрощению. Беда в том, что сама БД разошлась как пиражки по дочерним организациям и там наплодили своих переменных для новых нужд или переменных для хранения по сути одного и того же. надо еще и привести в соответствие что есть везде, что индивидуально, различия по названиям, деликатно убрать все дубликаты и тд. но забираться на эту гору лучше по ступенькам, или на лифте если есть готовое решение. решил делать так: 1ступенька вынести hstory в отдельную таблицу, что бы основная уже не тормозила 2. использовать jsonb вместо hstory 3. GiST + GIN индексы 4. обязательно добавить таблицу tkey где будут описаны все ключи (что за переменная за что отвечает) 5. сделать в tkey fk ключ на таблицу maintkey (таблица аналог tkey которая будет реплецироваться с главным сервером для того что бы была возможность привести в соответсвие все важные доп параметры на всех бд к одному знаменателю) 6. добавить репликацию 7. поиск и анализ дубликатов сейчас это только модель на черновике, любые ваши подсказки что лучше использовать для достижения цели мне очень помогут-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 22:41 |
|
||
|
как лучше реализовать и хранить доп параметры в очень большом справочнике
|
|||
|---|---|---|---|
|
#18+
Legushka, Я бы рекомендовал все обязательные (NOT NULL) параметры организовать в таблицу с обычной структурой: набор полей с правильными типами и названиями, соответствующими целям колонок. Это позволит индивидуально индексировать наиболее востребованные колонки (или группы колонок) — суть параметров. Если логически эту таблицу (думаю что “широкую”) можно разбить на несколько, то я бы так и сделал, повесив на все такие “под-таблицы” представление построенное на внешних связках. Идея в том, что если практика показывает наличие строго структурированных данных, то их следует в первую очередь выносить их из “кучи” (hstore или json) в строгую реляционную форму. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 22:54 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39244396&tid=1997217]: |
0ms |
get settings: |
7ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
150ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
28ms |
get tp. blocked users: |
1ms |
| others: | 240ms |
| total: | 447ms |

| 0 / 0 |
