Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2010.08.27;
Скачать: CL | DM;

Вниз

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

 
Демо ©   (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 для некоторых атрибутов, - возможно, возникнет необходимость использовать внешнее соединение, которое может исключить оптимальные планы запросов из рассмотрения.

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

(с) Том Кайт


 
vuk ©   (2010-04-24 01:19) [34]

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

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

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


 
Игорь Шевченко ©   (2010-04-24 01:28) [35]

vuk ©   (24.04.10 01:19) [34]

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

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

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

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


 
Германн ©   (2010-04-24 01:35) [36]


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

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


 
xayam ©   (2010-04-24 13:20) [37]


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

как мне кажется, это стандартная задача сохранения иерархических данных в базе, реализации видел несколько, сам использовал как пример реализацию 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


 
test ©   (2010-04-24 13:23) [38]

Демо ©   (23.04.10 19:40) [18]
Посмотри в интернете SQL тюнинг и проектирование БД.


 
xayam ©   (2010-04-24 13:41) [39]

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


 
Демо ©   (2010-04-24 14:24) [40]


> xayam ©


Спасибо. Похоже это что-то из этой оперы.
Посмотрю на структуру.



Страницы: 1 2 вся ветка

Текущий архив: 2010.08.27;
Скачать: CL | DM;

Наверх




Память: 0.6 MB
Время: 0.14 c
15-1265566198
palva
2010-02-07 21:09
2010.08.27
Весна скоро... Фото с натуры.


15-1267104405
GDI+
2010-02-25 16:26
2010.08.27
Вопрос знатокам ассеблера и современных процессоров


15-1264762579
И Павел
2010-01-29 13:56
2010.08.27
Стоит ли превращать сайт в файлообменник?


15-1275078583
Юрий
2010-05-29 00:29
2010.08.27
С днем рождения ! 29 мая 2010 суббота


15-1271316405
12
2010-04-15 11:26
2010.08.27
PHP. Как наследовать?