Структура таблиц

crautcher · May 15, 2012

спросил сперва на другом форуме , там мне ниче так никто и не ответил :

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

Avalon4eg · May 15, 2012

В голову тока приходит 2 таблицы.

первая с искомым словом, 2я с синонимами связанные по id слова, из первой таблицы

Edited May 15, 2012 by Avalon4eg

rus · May 15, 2012

один ко многим связь вроде как получается.

Быколай · May 15, 2012

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

А в текущей задаче вроде как каждое из слов может иметь множество ссылок на другие слова. Или я чего-то не понимаю?

PS: то есть я вижу одну таблицу со всеми словами, решение -- вторичный ключ указывающий на первое из группы синонимов, так? А в логике программы определять всю группу, слова, которые ссылаются на "первый" синоним.

PPS: т.е. как-то так вижу

CREATE TABLE `words` (
	`id` INT(10) UNSIGNED NULL AUTO_INCREMENT,
	`word` VARCHAR(255) NULL,
	`parent_synonym_id` INT UNSIGNED NULL,
	PRIMARY KEY (`id`),
	UNIQUE INDEX `word` (`word`),
	INDEX `parent_synonym_id` (`parent_synonym_id`)
)

MiksIr · May 15, 2012

Значить, стандартное один ко-многим, но только внешне.

CREATE TABLE words
(
  id integer NOT NULL,
  word text,
  CONSTRAINT words_pkey PRIMARY KEY (id )
)

CREATE TABLE word_syn
(
  word_id integer NOT NULL,
  syn_id integer NOT NULL,
  CONSTRAINT world_syn_pkey PRIMARY KEY (word_id , syn_id ),
  CONSTRAINT world_syn_syn_id_fkey FOREIGN KEY (syn_id)
      REFERENCES words (id) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE CASCADE,
)

word_id тут или счетчик группы синонимов, а лучше, что бы не путаться - id первого слова группы

В таблице прописываем эти группы синонимов.

words:
1;"синоним А 1"
2;"синоним Б 1"
3;"синоним А 2"
4;"синоним А 3"
5;"синоним Б 2"

word_syn:
1;1
1;3
1;4
2;2
2;5

Ну и запрос

SELECT 
  syn.word
FROM 
  public.words src 
  INNER JOIN 
  public.word_syn link
  ON (src.id = link.syn_id)
  INNER JOIN
  public.word_syn link2
  ON (link.word_id = link2.word_id)
  INNER JOIN
  public.words syn
  ON (link2.syn_id = syn.id)
WHERE 
  src.word = 'синоним А 1';

Edited May 15, 2012 by MiksIr

rus · May 16, 2012

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

s0rr0w · May 16, 2012

On 5/16/2012 at 5:59 AM, rus said:
хотя я вот тут подумал..., а что если все слова синонимы поместить в одну таблицу и разделить их ну скажем можно запятыми, или вертикальными черточками и если по поиску, или по клику по ссылке на одно из слов - делать запрос и выбирать остальные слова... ну там можно через эксплоуд бить, или еще как?

Только так и надо решать. Можно сразу хранить json-объект (вернее его текстовое представление)

Тогда запрос будет простым и быстрым.

MiksIr · May 16, 2012

Это будет говнокод.

LunatiK · May 16, 2012

Слово     | Группа
-------------------
пить      | 1
бухать    | 1
колдырять | 1
квасить   | 1
курить    | 2
смолить   | 2
дымить    | 2
пыхать    | 2
-------------------

Ищем слово -> Определяем группу синонимов -> берём все слова из группы синонимов

Или я не прав, и есть более простые решения ?

MiksIr · May 16, 2012

Да, точно, так проще.

s0rr0w · May 16, 2012

On 5/16/2012 at 9:50 AM, MiksIr said:
Это будет говнокод.

Да конечно! Во всем мире это используется в высоконагруженных системах, а у него это говнокод.

:rofl:

On 5/16/2012 at 9:59 AM, LunatiK said:
Или я не прав, и есть более простые решения ?

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

MiksIr · May 16, 2012

Давай ты еще раскажешь про высоконагруженные проекты во всем мире, ага.

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

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

Quote
Эта структура может быть использована для хранения нормализованных данных, но не для вывода. Потому что там JOIN надо применять.

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

Edited May 16, 2012 by MiksIr

s0rr0w · May 16, 2012

On 5/16/2012 at 12:17 PM, MiksIr said:
Высоконагруженные проекты не работают с денормализованными данными, они их создают из нормализованных в виде кеша.

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

On 5/16/2012 at 12:17 PM, MiksIr said:
В какую жопу отправится ваш высоконагруженный проект когда понадобится, не дай бог, удалить или поменять одно слово, остается только догадываться, ибо, к счастью, никто так не делает.

В чем проблема? Вам нужно всего лишь обновить n строк, где n - количество синонимов в группе. Это предсказуемое количество.

Quote
JOIN можно и нужно применять, когда нужно. Если вы думаете, что разбив джойн на два запроса вы всегда получите адский профит, вы безумно ошибаетесь.

Только весь прикол в том, что один запрос оффлайновый, а второй - онлайновый. И да, я получу адский профит на всех этапах. Потому что мне не нужно будет собирать каждый раз таблицу в удобоваримый для передачи дальнейшим обработчикам вид, например, в тот же json.

MiksIr · May 16, 2012

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

Если затраты на обновление кеша у вас первышают работу с базой, значит пора уволить архитектора и пригласить того, кто хоть немного в этом понимает. И в создании кеша, и в его актуализации.

Quote
В чем проблема? Вам нужно всего лишь обновить n строк, где n - количество синонимов в группе. Это предсказуемое количество.

Искать вы это слово как будете в хранимом JSON-е? Скан всей таблицы без индекса, ага. У вас же хайлоад, миллионы записей данных... :facepalmxd:

Quote
Только весь прикол в том, что один запрос оффлайновый, а второй - онлайновый. И да, я получу адский профит на всех этапах. Потому что мне не нужно будет собирать каждый раз таблицу в удобоваримый для передачи дальнейшим обработчикам вид, например, в тот же json.

Еще раз, не мешаейте в кучу кеш и работу с данными. Хоть для этого найдите соображение. Что сначала проектируются данные и работа с ними, а потом, если это место становится узким - реализуют заранее продуманные заглушки по кешированию. По-этому нефиг лезть с кешированием данных в тему о структуре исходных данных и работе с ними. В 100% случаев обсуждаемых на этом форуме трудозатраты по созданию нормального кеша и обслуживание усложненного кода никогда не оправдают копеечный выигрыш, который тут предлагается.

s0rr0w · May 16, 2012

On 5/16/2012 at 12:45 PM, MiksIr said:
Если затраты на обновление кеша у вас первышают работу с базой, значит пора уволить архитектора и пригласить того, кто хоть немного в этом понимает. И в создании кеша, и в его актуализации.

Почитайте про новую архитектуру Гугла. С их объемами это вполне реально.

Quote
Искать вы это слово как будете в хранимом JSON-е?

:rofl:

А кто вам сказал, что нужно искать именно в json'e? Вариант с двумя полями вас не устраивает? Одно поле - слово, второе - json. Ищется по первому полю, результат берется из второго.

Quote
Еще раз, не мешаейте в кучу кеш и работу с данными.

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

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

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

MiksIr · May 16, 2012

Quote
Почитайте про новую архитектуру Гугла. С их объемами это вполне реально.

А что я там дожен увидеть? Ткните пальцем. Интересует именно денормализованное неконсистентное хранение с многократно дублированной информацией в качестве основного хранилища, а не кеша.

Quote
А кто вам сказал, что нужно искать именно в json'e? Вариант с двумя полями вас не устраивает? Одно поле - слово, второе - json. Ищется по первому полю, результат берется из второго.

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

О том, что у вас будет отстутствовать хоть какая-то проверка консистенции данных, можно и не говорить, вы же понимаете это, да?

Quote
Вы задачу человека внимательно прочитали? Ему нужно быстро искать данные и легко получать связку синонимов. Мой вариант идеально подходит для решения задачи, мало того, хорошо масштабируется и позволит выгружать данные в тот же редис, монго или мемкешед.
А как именно будет происходить работа с нормализованными данными, это уже не столь важно. Тут применять классическое решение и не заморачиваться: таблица-словарь со словами и таблица связей.

Да, в отличие от вас я прекрасно понял, что автор вообще нихрена не смыслит. И не стал показывать крутость знаний хайлоада, а объяснил на классическом SQL. Ваш вариант - всего лишь кеш. Вас спросили как данные хранить, а вы рассказли, как их кешировать. Да еще с отсылками на гипотетический хайлоад. Сначала нужно научится задачи классически решать, а потом уже читать про архитектуры хайлоадов и сувать их куда не попадя. Испугался одного джойна и засрал таблицу тоннами говна "денормализованных данных"... классика. Не нужна там таблица связей, LunatiK давно уже увидел самое простое решение, и выборка из него будет в один джойн таблицы на себя.

Спорить больше не о чем.

s0rr0w · May 16, 2012

On 5/16/2012 at 1:59 PM, MiksIr said:
А что я там дожен увидеть? Ткните пальцем. Интересует именно денормализованное неконсистентное хранение с многократно дублированной информацией в качестве основного хранилища, а не кеша.

Этого в описании архитектуры нет. И при чем тут превышение трафика обновления кеша над скоростью запроса данных? :blink:

On 5/16/2012 at 1:59 PM, MiksIr said:
Речь идет не о выборке, а об обслуживании - нарисуйте алгоритмы замены слова, удаления слова, добавление нового слова.
О том, что у вас будет отстутствовать хоть какая-то проверка консистенции данных, можно и не говорить, вы же понимаете это, да?

Итак, имеем две таблицы

| id | word | syn |

и | id | syn_id |

Существует два процесса - обновление данных и денормализация.

При обновлении мы должны найти слово в базе, изменить его значение word и обнулить syn. Вытаскиваем данные по синонимам слова.

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

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

Далее запускаем процедуру денормализации для списка синонимов и для искомого объекта, если это не удаление.

On 5/16/2012 at 1:59 PM, MiksIr said:
Вас спросили как данные хранить, а вы рассказли, как их кешировать.

Меня спрашивали как данные выводить, а не хранить.

On 5/16/2012 at 1:59 PM, MiksIr said:
Не нужна там таблица связей, LunatiK давно уже увидел самое простое решение, и выборка из него будет в один джойн таблицы на себя.

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

Слову "делать" синонимами могут быть слова "изготавливать" и "реализовывать", но вот слову "реализовывать" может быть синонимом слово "продавать". А "продавать" не является синонимом слово "делать".

On 5/16/2012 at 1:59 PM, MiksIr said:
Спорить больше не о чем.

Конечно не о чем. :rofl:

MiksIr · May 16, 2012

Quote
Далее запускаем процедуру денормализации для списка синонимов и для искомого объекта, если это не удаление.

Quote
Только так и надо решать. Можно сразу хранить json-объект (вернее его текстовое представление)

Quote
А кэш иногда проще вообще не использовать, так как затраты на обновление кеша могут привысить затраты на обработку запроса базой.

Ну хорошо хоть перестали убеждать, что данные нужно прямо так и хранить. Теперь осталось научится рассказывать человеку как хранить данные, а потом, если нужно, рассказать как кешировать. А не рассказывать, что данные нужно сразу хранить кешированные (для понимания - денормализованные в данном случае = кешированные), не упомянув о том, как же их хранить изначально. Ибо решение о кешировании принимается исходя из архитектуры проекта, а не из задачи "как мне сделать".

Quote
В этом решении есть проблема. Две группы слов могут иметь пересечение синонимов, но не полностью совпадать. Тогда его решение рассыпается как карточный домик.

Да, тогда или вторая таблица, как я писал выше, или дублирование слов в одной таблице как омонимов.

Edited May 16, 2012 by MiksIr

s0rr0w · May 16, 2012

On 5/16/2012 at 4:19 PM, MiksIr said:
Ну хорошо хоть перестали убеждать, что данные нужно прямо так и хранить.

Я понял, что вас смущает. Из контекста не нужно вырывать. Без предыдущего поста rus'а мои слова действительно можно истолковать как хранение. Нет, хранить так без нормального представления противопоказано.

On 5/16/2012 at 4:19 PM, MiksIr said:
Да, тогда или вторая таблица, как я писал выше, или дублирование слов в одной таблице как омонимов.

Edited May 16, 2012 by s0rr0w

LunatiK · May 16, 2012

On 5/16/2012 at 12:11 PM, s0rr0w said:

On 5/16/2012 at 9:59 AM, LunatiK said:
Или я не прав, и есть более простые решения ?
Эта структура может быть использована для хранения нормализованных данных, но не для вывода. Потому что там JOIN надо применять. В моем варианте нужно найти всего одну строку и как есть отправить на обработку.

Я что-то не очень понял куда там JOIN можно вставить, если для дискутирующих это очевидно - то покажите пример

slovo     | gruppa
-------------------
пить      | 1
бухать    | 1
колдырять | 1
квасить   | 1
курить    | 2
смолить   | 2
дымить    | 2
пыхать    | 2
-------------------

Я это все прдставлял так:

запрос слово: 'квасить'

SELECT `slovo` FROM `table` WHERE `gruppa` = (SELECT `gruppa` FROM `table` WHERE `slovo` = 'квасить')

?

MiksIr · May 16, 2012

Таблицу можно джойнить саму на себя

SELECT t2.slovo FROM table t1 INNER JOIN table t2 ON (t1.group = t2.group) WHERE t1.slovo='квасить';

LunatiK · May 16, 2012

On 5/16/2012 at 5:25 PM, MiksIr said:
Таблицу можно джойнить саму на себя
SELECT t2.slovo FROM table t1 INNER JOIN table t2 ON (t1.group = t2.group) WHERE t1.slovo='квасить';

Как-то идея понятна, но рабочего примера для просветления не увидел

Осознал, прозрел.

Edited May 16, 2012 by LunatiK

LunatiK · May 16, 2012

Тогда вернусь к вопросу:

On 5/16/2012 at 12:11 PM, s0rr0w said:
Потому что там JOIN надо применять. В моем варианте нужно найти всего одну строку и как есть отправить на обработку.

Чем плох JOIN? не уж-то большую нагрузку создаст? В Варианте с JSON будет избыточность данных, насколько она оправдана(Удобство ввода? Редактирования? С поиском и выводом всё ясно.) ?

s0rr0w · May 17, 2012

On 5/16/2012 at 7:11 PM, LunatiK said:
Чем плох JOIN? не уж-то большую нагрузку создаст? В Варианте с JSON будет избыточность данных, насколько она оправдана(Удобство ввода? Редактирования? С поиском и выводом всё ясно.) ?

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

Избыточность не страшна, так как на одну процедуру записи данных будут миллионы чтения. И что лучше, миллион раз применять JOIN и процедуру пост-обработки данных, или сделать это один раз и потом пользоваться результатами? Я за последний вариант.

rus · May 17, 2012

On 5/16/2012 at 5:20 PM, LunatiK said:
SELECT `slovo` FROM `table` WHERE `gruppa` = (SELECT `gruppa` FROM `table` WHERE `slovo` = 'квасить')


SELECT `slovo` FROM `table` WHERE `gruppa` = (SELECT `gruppa` FROM `table` WHERE `slovo` = LIKE '%search%' || `gruppa` = int($_GET['gruppa']))

поиск+переход по ссылке

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

MiksIr · May 17, 2012

Да быстро join будет работать, быстро. Нужно очень быстрое решение - берите сфинкс, скармливайте ему статьи с синонимами и ищите.

А то, что предлагает s0rr0w - это на пустом месте родить сотни мегабайт ненужных, дублированных данных ради неопределенной экономии.

Edited May 17, 2012 by MiksIr

Sign In

Структура таблиц

Question

Link to comment

Share on other sites

35 answers to this question

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Обсуждения

Important Information