Ассоциативные массивы в БД

← →
Демо © (2010-04-23 18:19) [0]

Сталкивался кто-нибудь с реализацией?

← →
vuk © (2010-04-23 18:23) [1]

Э... Имеется в виду табличка из двух полей - Key-Value?

← →
Демо © (2010-04-23 18:24) [2]

Откуда такой вопрос? - Поясню, - исключительно из лени.

Мысль возникла при разборке HTML-страниц с огромным количеством полей.
Как правило, все данные хранятся в тегах, т.е. имеют стандартный вид ассоциативной пары FieldName=FieldValue.

Лень выписывать имена этих полей при кодировании для записи в БД привела к мысли реализовать запись или доступ к БД функциями с параметром - ассоциативный массив.

Это позволяет только один раз при создании таблицы указать поля, которые должны быть в ней.
Затем все обращения происходят по списку параметров, который формируется динамически.

← →
Демо © (2010-04-23 18:29) [3]

На данный момент реализовал такой вид для тестирования:
1. Каждая виртуальная "ассоциативная таблица" включает в себя 2 логических:
- справочник полей;
- данные

Например:

Для таблицы Temp соответствуют 2 таблицы:
- CREATE TABLE TempF (id INTEGER PRIMARY KEY, FName TEXT, FieldName TEXT)
- CREATE TABLE TempV (id INTEGER PRIMARY KEY, F01 TEXT, F02 TEXT, ...,Fn TEXT)

← →
Демо © (2010-04-23 18:32) [4]

Пример содержимого:
Например, для таблицы с полями Inn, FIO, ShortName:

TempF содержит записи:
"Inn","F00" "FIO","F01" "ShortName","F02"
А таблица TempV:

"111111111111","Сидоров А.В.", "АВ"

← →
Демо © (2010-04-23 18:32) [5]

Никто не встречался с подобным?

← →
Игорь Шевченко © (2010-04-23 18:41) [6]

Что такое ассоциативный массив и как он связан с базой данных ?

← →
Демо © (2010-04-23 18:45) [7]

> Игорь Шевченко © (23.04.10 18:41) [6]
> Что такое ассоциативный массив и как он связан с базой данных
> ?

Ассоциативный массив - массив, состоящий из множества пар "ключ,значение"

Например
TAssociate=record Name: String; Value: String; end;

В Delphi подобное реализовано в классах списках (TStringList, например):
Каждая запись может содержать пару Name=Value.

Соответственно есть методы доступа и поиска.

← →
Демо © (2010-04-23 18:46) [8]

Упоминаний БД в связи с ассоциативными массивами я не нашёл в интернете пока.

← →
vuk © (2010-04-23 18:59) [9]

to Демо © (23.04.10 18:45) [7]:

> Ассоциативный массив - массив, состоящий из множества пар
> "ключ,значение"

Есчо рас спрашываю. Чем не устраивает табличка из двух полей?

← →
sniknik © (2010-04-23 19:03) [10]

> табличка из двух полей?
или рекордсет в памяти.

← →
Демо © (2010-04-23 19:06) [11]

> Есчо рас спрашываю. Чем не устраивает табличка из двух полей?

Что в ней будет находиться?

← →
vuk © (2010-04-23 19:08) [12]

to Демо © (23.04.10 19:06) [11]:

> Что в ней будет находиться?

Пары "ключ,значение", ясен пень.

← →
Демо © (2010-04-23 19:09) [13]

> vuk © (23.04.10 19:08) [12]
> to Демо © (23.04.10 19:06) [11]:> Что в ней будет находиться?
> Пары "ключ,значение", ясен пень.

В таком случае, как мне записать в неё 3 записи "Номер, фамилия, телефон, адрес", например?

← →
Демо © (2010-04-23 19:11) [14]

> vuk © (23.04.10 19:08) [12]
> to Демо © (23.04.10 19:06) [11]:> Что в ней будет находиться?
> Пары "ключ,значение", ясен пень.

Предлагаешь для каждой пары собственную таблицу организовывать?

← →
vuk © (2010-04-23 19:15) [15]

to Демо © (23.04.10 19:09) [13]:

> В таком случае, как мне записать в неё 3 записи "Номер,
> фамилия, телефон, адрес", например?

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

← →
vuk © (2010-04-23 19:18) [16]

to Демо © (23.04.10 19:11) [14]:

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

Я предлагаю для начала четко объяснить самому себе, чего же именно хочется.

← →
Anatoly Podgoretsky © (2010-04-23 19:20) [17]

> Игорь Шевченко (23.04.2010 18:41:06) [6]

Таблица с ключом, как индекс.
В БД практически любая таблица представляет собой ассоциативный массив

← →
Демо © (2010-04-23 19:40) [18]

> vuk © (23.04.10 19:15) [15]
> to Демо © (23.04.10 19:09) [13]:> В таком случае, как
> мне записать в неё 3 записи "Номер, > фамилия, телефон,
> адрес", например?В ассоциативном массиве, в соответствии
> с данным выше определением, это хранить нельзя, т.к. это
> не представляет из себя пару "ключ,значение".

Я вроде бы привёл пример того, что нужно.
Давай сформулирую ещё раз.

Возьмём задачу по разбору HTML-страниц и сохранению полученных данных.

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

Допустим, общее количество полей насчитывает 300 неуникальных(!).

Пусть их возможно разделить на 3 группы примерно по 100 полей.
Поля в из разных групп могут иметь одинаковый смысл, но разное наименование.

При этом даже для одной группы набор полей, полученных со страницы HTML в некоторый момент времени, может различаться во времени.

Каким образом для полей с разными наименованиями сохранять и выбирать одни и те же данные?

← →
Игорь Шевченко © (2010-04-23 20:20) [19]

Anatoly Podgoretsky © (23.04.10 19:20) [17]

Как бы я про то же.

Демо © (23.04.10 19:40) [18]

> Возьмём задачу по разбору HTML-страниц и сохранению полученных
> данных.
>
> Сайт - многоуровневая структура со множеством страниц, некоторым
> образом связанных между собой.
> При выводе страниц используется очень много полей, разных
> по наименованию, но имеющих одинаковый смысл для какого-
> то типа выводимых страниц (скажем, страницы разной тематики
> с общими данными).
>
> Допустим, общее количество полей насчитывает 300 неуникальных(!
> ).
>
> Пусть их возможно разделить на 3 группы примерно по 100
> полей.
> Поля в из разных групп могут иметь одинаковый смысл, но
> разное наименование.
>
> При этом даже для одной группы набор полей, полученных со
> страницы HTML в некоторый момент времени, может различаться
> во времени.
>
> Каким образом для полей с разными наименованиями сохранять
> и выбирать одни и те же данные?

Причем тут ассоциативный массив и тем более база данных ?

Эта...HMTL в XML не ? Не из той оперы ?

← →
Демо © (2010-04-23 20:30) [20]

> Причем тут ассоциативный массив и тем более база данных
> ?Эта...HMTL в XML не ? Не из той оперы ?

Из БД выборка в любом случае быстрее, чем из XML.
И XML не решает вопроса

> Каким образом для полей с разными наименованиями сохранять
> и выбирать одни и те же данные?

← →
Jeer © (2010-04-23 20:53) [21]

> Из БД выборка в любом случае быстрее, чем из XML.

Это уже хорошо, что принимается за факт.

Дальше начни думать над искорками знания, просыпанными над твоей "проблемой".

← →
Демо © (2010-04-23 20:57) [22]

> > Из БД выборка в любом случае быстрее, чем из XML.Это уже
> хорошо, что принимается за факт.Дальше начни думать над
> искорками знания, просыпанными над твоей "проблемой".

Замечательное высказывание. Ценно само по себе, потому что гениально в своей искромётной тупости.

← →
Jeer © (2010-04-23 21:00) [23]

> Ценно само по себе,

Естественно.
Цени.
Можешь даже начать размышлять об этом.

← →
Игорь Шевченко © (2010-04-23 21:04) [24]

> При выводе страниц используется очень много полей

Что такое поля на страницах сайта "Мастера Delphi" ? Сколько не смотрю, никаких полей в упор не вижу.

Что такое поля на сайте Росбизнесконсалтинг-а ?

>
> Допустим, общее количество полей насчитывает 300 неуникальных(!
> ).
>
> Пусть их возможно разделить на 3 группы примерно по 100
> полей.
> Поля в из разных групп могут иметь одинаковый смысл, но
> разное наименование.
>
> При этом даже для одной группы набор полей, полученных со
> страницы HTML в некоторый момент времени, может различаться
> во времени.
>
> Каким образом для полей с разными наименованиями сохранять
> и выбирать одни и те же данные?

Теперь то же самое два раза и помедленнее. Причем тут какие-то наборы полей, ассоциативные массивы и прочие умные слова ?

← →
Демо © (2010-04-23 21:14) [25]

> Что такое поля на страницах сайта "Мастера Delphi" ? Сколько
> не смотрю, никаких полей в упор не вижу.

Ну то, что их не видно после рендеринга на странице, это понятно.

> Теперь то же самое два раза и помедленнее. Причем тут какие-
> то наборы полей, ассоциативные массивы и прочие умные слова
> ?

Есть пары "CustId, <значение>" и "OrgId, <значение>".
"<значение>" в них одно и то же, но название полей разное.

Чтобы было понятнее о чём речь, вот разбор тегов с одной из страниц

<Purchases> <Purchase> <purchID>6953</purchID> <OrgBuID>819</OrgBuID> <CustBuID>819</CustBuID> <purchCode>201004/819/6953</purchCode> <purchName>Поставка канцелярских товаров</purchName> <purchState>public</purchState> <PurchStateName>Опубликован</PurchStateName> <SMP>Нет</SMP> <purchAmount>3730000.00</purchAmount> <purchCoverAmount>186500.00</purchCoverAmount> <purchCurID>1</purchCurID><orgContacts> <orgName>Центральная базовая таможня</orgName> <orgPlace>107258, город Москва, Москва, Игральная, 1, ,</orgPlace> <orgPostAddress>121087, город Москва, Москва, Новозаводская, 11/5, ,</orgPostAddress> <orgEMail>okononenko83@mail.ru</orgEMail> <orgPhones>7819828</orgPhones></orgContacts> <custContacts> <custName>Центральная базовая таможня</custName> <custPlace>107258, город Москва, Москва, Игральная, 1, ,</custPlace> <custPostAddress>121087, город Москва, Москва, Новозаводская, 11/5, ,</custPostAddress> <custEMail>okononenko83@mail.ru</custEMail> <custPhones>7819828</custPhones> </custContacts> <purchDescription>г. Москва, ул. Новодмитровская, д. 5а. транспортом Поставщика</purchDescription> <acceptHREF>/tradezone/admin/purchase/AcceptRequests.aspx?purchID=6953</acceptHREF> <PublicDate>16.04.2010 15:14</PublicDate> <RequestDate>07.05.2010 10:00</RequestDate> <RequestAcceptDate>11.05.2010 00:00</RequestAcceptDate> <AuctionBeginDate>14.05.2010 10:00</AuctionBeginDate> <AuctionEndDate>14.05.2010 10:10</AuctionEndDate> <purchCreateBy>0</purchCreateBy> <purchCreateAt>2010-04-16T15:14:06.287</purchCreateAt> <PurchaseCommentsStatus>1</PurchaseCommentsStatus> <OrgName>Центральная базовая таможня</OrgName> <purchAddonExist>нет</purchAddonExist> <RowNumber>1</RowNumber> </Purchase>

← →
Демо © (2010-04-23 21:14) [26]

Я понимаю, что это структура XML.
Но мне не нужно хранить данные в XML.

← →
Демо © (2010-04-23 21:20) [27]

> Демо © (23.04.10 18:32) [4]
> Пример содержимого:Например, для таблицы с полями Inn, FIO,
> ShortName:TempF содержит записи:"Inn","F00""FIO","F01""ShortName",
> "F02"А таблица TempV:"111111111111","Сидоров А.В.", "АВ"

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

т.е.

TempF содержит записи:
"Inn","F00"
"FIO","F01"
"ShortName","F02"
"Code","F00"
"UseNamer","F01"

Теперь "Inn" и "Code" ссылаются на одно и то же поле в таблице с данными - "F00".

Эта конструкция надумана, конечно.
Реализовать я уже реализовал этот вариант, посмотрю, насколько удобно будет.

Потому и спрашиваю, имел ли кто дело с подобными задачками.

← →
Jeer © (2010-04-23 22:31) [28]

> Потому и спрашиваю,

Считай, что поговорил сам с собой - при депрессии, очень даже полезно.

← →
Игорь Шевченко © (2010-04-23 22:41) [29]

> Я понимаю, что это структура XML.
> Но мне не нужно хранить данные в XML.

как бы по-прежнему непонятно, причем тут ассоциативные массивы. Ты хочешь XML в реляционную структуру разложить ? Это можно, но для конкретной схемы.

← →
Jeer © (2010-04-23 23:02) [30]

> разложить ?

Разложить, а также воссоздать можно почти все - и оттуда и обратно.
Были бы известны задача и резон.
Пока от спрашивающего поток инфы идет на уровне детсада.

← →
Демо © (2010-04-23 23:09) [31]

> как бы по-прежнему непонятно, причем тут ассоциативные массивы.
> Ты хочешь XML в реляционную структуру разложить ? Это можно,
> но для конкретной схемы.

Да XML разложить невелика проблема.
Смысл в том, что имена полей в таблицах не фиксированы, и с любой колонкой в таблице можно ассоциировать новый ключ абсолютно прозрачно для пользователя.

Т.е. есть у нас таблица с произвольным набором полей в БД.
Есть 2 программы, которые могут запрашивать эти данные.
Проблема в том, что наименования полей и их количество в обоих программах используется разные.

Сводя доступ к полям таблицы как к ассоциативному массиву, мы можем в одной таблице хранить все эти данные, не заморачиваясь с наименованиями полей.

Например, два запроса для разных программ
SELECT Inn, Fio FROM MyTable
и
SELECT Code, UserNamer FROM MyTable

в разных программах отберут одни и те же данные.

← →
Демо © (2010-04-23 23:11) [32]

Удалено модератором

← →
Игорь Шевченко © (2010-04-24 00:08) [33]

> Да XML разложить невелика проблема.
> Смысл в том, что имена полей в таблицах не фиксированы,
> и с любой колонкой в таблице можно ассоциировать новый ключ
> абсолютно прозрачно для пользователя.
>
> Т.е. есть у нас таблица с произвольным набором полей в БД.
>
> Есть 2 программы, которые могут запрашивать эти данные.
> Проблема в том, что наименования полей и их количество в
> обоих программах используется разные.
>

У тебя где-то точно лишние колеса. У велосипеда их обычно два.

> Сводя доступ к полям таблицы как к ассоциативному массиву,
> мы можем в одной таблице хранить все эти данные, не заморачиваясь
> с наименованиями полей.

Ассоциативный массив - это не мантра, которая будучи пропета, волшебным образом нормализует ненормализуемое.

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

create table objects (oid int pimary key, name varchar2(255));
create table attributes (attrid int primary key, attrname varchar2(255),
datatype varchar2(25));
create table object_attributes (oid int, attrid int, value varchar2(4000),
primary key (oid,attrid));
create table links (oid1 int, oid2 int, primary key (oid1, oid2));

Но как такая модель работает ? Простой запрос select first_name, last_name from person трансформируется в соединение трех таблиц с аггрегированием, более того, если имеются атрибуты NULLABLE - в таком случае может не быть строки в таблице object_attributes для некоторых атрибутов, - возможно, возникнет необходимость использовать внешнее соединение, которое может исключить оптимальные планы запросов из рассмотрения.

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

(с) Том Кайт

to Игорь Шевченко © (24.04.10 00:08) [33]:

> Например, хорошо известно, что можно представить любой объект
> в базе данных используя только четыре таблицы

Вот почти такое мне и пришлось однажды нагородить. Потому, что требованием было создание юзером новых типов объектов со своими свойствами и т.д. Все это живо и развивается до сих пор.

vuk © (24.04.10 01:19) [34]

Если бы только тебе...Нагородить-то несложно, использовать потом, как выясняется, не очень удобно.

Но для небольших случаев и объемов - почему бы и нет ? У нас это использовалось при генерации какой-то полуотчетности по виду, набору и расположению различного рода атрибутов, задаваемому пользователем.

В базе хранилась только информация, а все мамбл-ванго происходили уже на клиенте, то есть, запросов, о которых пишет Кайт, нам выдавать не пришлось.

Кстате вот MS Outlook, если мне память не изменяет, позволяет на запись о контакте только различных атрибутов, определяемых пользователем, навешать. Даже, по-моему, искать по ним можно.

> Кстате вот MS Outlook, если мне память не изменяет, позволяет
> на запись о контакте только различных атрибутов, определяемых
> пользователем, навешать.

Фраза не закончена

> Потому и спрашиваю, имел ли кто дело с подобными задачками.

как мне кажется, это стандартная задача сохранения иерархических данных в базе, реализации видел несколько, сам использовал как пример реализацию drupal"а - модуль таксономия - http://drupaler.ru/tables тебе нужны примерно такие таблицы - drupal/vocabulary, drupal/vocabulary_node_type, drupal/term_node, drupal/term_relation, drupal/term_synonym, drupal/term_node, drupal/term_hierarchy

соответственно, если подогнать твою задачу под друпал, то "ТЕРМИН" будут означать - одно из названий тегов или по-другому ключ ассоциативного массива (таблица term_data), причем хранить эти теги можно будет в единственном экземпляре, даже если он встречается у тебя в разных файлах, отличаться будут только их значения (в таблицу term_node добавляется одно поле для хранения этого значения). Плюс то, что в друпале называется словарем - у тебя будет соответствовать определенному файлу, зная vid словаря, можно сформировать весь файл используя sql-запрос.

можешь еще почитать Джона Вандюка там у него есть про таксономию. Хотя все таблицы из друпала тебе точно не понадобятся - уж слишком они нормализованы и много лишнего. Например, поле из vocabulary_node_type можно перенести в vocabulary. term_relation и term_synonym - не нужны вообще скорей всего. Плюс нужно добавить какое-то поле в term_hierarchy целого типа для указания порядка следования тегов.

> Плюс нужно добавить какое-то поле в term_hierarchy целого
> типа для указания порядка следования тегов.

хотя нет, лучше использовать для этого поле weight из таблицы term_data.

ой блин [42] - неправильно, поскольку там хранятся только имена тегов, сорри :)

В общем, проект горит, и испытать новую технологию придётся оставить на будущее...

Мда, за 15 минут до дедлайна прикручивать новую технологию это сильно. Я бы так не смог.

> test © (25.04.10 09:47) [45]
> Мда, за 15 минут до дедлайна прикручивать новую технологию
> это сильно. Я бы так не смог.

Что поделать. Потратил сутки. но не зря.
После того как освобожусь продолжу исследования в этом направлении.

А не проще сделать так:

table 1
fields purchase_id, key_name, key_value

и уникальный индекс на первые 2 поля.

select key_name, key_value from 1 where purchase_id = 3 выдаст готовый массив ключ=значение для конкретного пурчейза.

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

> SPeller © (26.04.10 05:10) [47]
> А не проще сделать так

так он же сказал что ему нужно сохранять многоуровневые данные, а у тебя только в плоском виде. Не?

Ассоциативные массивы в БД Найти похожие ветки