- 1
- 2
//Список категорий записан в строках с разделителем вида "23", "11||12" или даже "3||8||12||43||23"
SELECT id, pagetitle FROM modx_site_content WHERE categores LIKE "%|[[*id]]" OR categores LIKE "%|[[*id]]|%" OR categores LIKE "[[*id]]|%" OR categores="[[*id]]"
За выбор по лайку в OLTP надо выгонять из профессии навсегда, особенно когда в categores лежит какая-то ненормализованная хуита
id = 1, category = 2
id = 1, category = 5
id = 2, category = 2
id = 2, category = 3
Уникальный ключ будет комплексный: (id, category)
Тогда можно проиндексировать столбец category и доставать все id, соответствующие категории, мгновенно.
Тогда купи себе скорее хорошую книжку!
А что начитаются всякой mysql.ru, а потом не знают какие бывают виды объединений, не знают что такое CTE и не умеют пользоваться констреинтами.
разумеется в системах такого размера не может быть реляционных субд
>>хранятся в графовой базе данных
ЧИТД
Но во-первых проблемы facebook надо решать когда ты размером с facebook, а во-вторых google тоже имеет весь мир, и совсем не хранит все данные в одной колонке mysql:)
Там наверняка есть serp.php, и там написано
$resultat = mysql_query("SELECT * from stranici where tekst like '%$zapros%'")
Роман, подтверди
... своему однобокому пониманию какой-нибудь хуйни.
https://backchannel.org/blog/friendfeed-schemaless-mysql
Но для поиска по значению произвольного поля им пришлось для каждой колонки строить отдельную таблицу с индексом. Это довольно сложное решение, но они к нему пришли, потому что не хотели использовать JOIN при выдаче по id.
Кстати, изучи все типы JOIN, оператор GROUP BY и так называемые агрегатные функции.
Неудобна для отчетов (надо делать кучу джойнов, медленно).
OnLineAanalysisProcessing: возможно денормализованная база, возможно генерируется раз в N часов по OLTP. Удобна для быстрого получения отчетов. Может быть как обычная реляционная СУБД так и OLAP куб.
OLTP
OLAP (реляционный, не куб)
Сайтов, требующих базы данных - полпроцента. Остальным и так нормально.
Удваиваю. За table_full_access надо гнать.
Сталкивался с похожей задачей. Писал парсеры: https://gist.github.com/kai3341/45cd4f06a1ed346a999629c66a14199e
Удивительно, что в SQL отсутствует такая простая (для императивных языков) штука, как split. Удивительно, что приходилось изобретать велосипеды
PS: а что, отформатировать код в читабельном виде религия не позволяет?
Потому что первая нормальная форма говорит нам что ненужно хранить в поле коллекции чего-либо.
Но суха теория, мой друг: в postgresql и ms-sql можно хранить XML и JSON. Можно строить по ним индексы, и даже дергать данные через XQuery.
Вон даже в mysql завезли
regexp_split_to_array, regexp_split_to_table штатно в постгресе делают то, как называются - сплитят строку в массив или setof по паттерну
в оракле это через жопу, но тоже есть, но учитывая, что массивы/коллекции в оракле - это стыд и позор + контекст переключения sql<->plsql тоже стыд и позор, то изложенный ниже вариант может быть самым "адекватным" и самому аналог писать не стоит:
Или на это тоже нет стандарта?
Этот рфц — скорее рекомендация, чем стандарт. Его в принцепе невозможно соблюдать на 100%, в нём ни слова про юникод, например.
Я считаю, что разумно сделать символ разделителя "параметром" этого "стандарта".
Это примерно как не знать что такое цикл, и пытаться писать приложения