........... OrientDB ...........

[Gozar]

Orient не пробывал

Я как раз сейчас.

для linux:
Если установлена java, то просто распаковываешь архив и: sh ./server.sh

В комплекте админка (http://localhost:2480/), чуть-чуть похожа на phpmyadmin, есть графическая утилита (кавайная) для визуализации связей.

много плюшек

Да, да, очень зацепило.

[Gozar]

db огонь.

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

select id, name, out('Type') as type, chain('Thematic') as thematic from Star where id=2015
{
id:2015, name:'Bada', type:'Big', thematic:[{
  id:101, 
  name: 'bla'
},
{
  id:102, 
  name: 'blu'
}]
}

А не то, что сейчас:

select id, name, out('Type') as type, out('Thematic').id as th_id, out('Thematic').name as th_name from Star where id=2015
{
id:2015, name:'Bada', type:'Big', th_id:[101, 102], th_name: ['bla', 'blu']
}

Целая миллисекунда нужна на пересборку в объект.

[Zend]

Я просто храню всё списком. А где нужно, достаю его из БД и обрабатываю волшебным рекурсивным методом (чаще всего на клиенте). И я не встретил не одной задачи, где бы меня этот подход не выручил. Правда я и соц сеть не писал ни когда, так что возможно дело в недостатке опыта.

п.с.: отдаю своё предпочтение PostgreSQL (юзаю phpPgAdmin, хотя пишу на nodejs)

[Gozar]

Я просто храню всё списком

Что ты хранишь списком? А зачем тебе БД. Просто храни гигантский JSON в памяти, если у тебя её конечно хватит...

обрабатываю волшебным рекурсивным методом

Если у тебя БД будет метров на 300-500-1000-терабайт, тоже будешь все рекурсивным методом обрабатывать на клиенте?

PostgreSQL

Приведи пример, как ты сделаешь тоже что я привел выше с помощью одного запроса

[Zend]

Просто храни гигантский JSON в памяти

ORDER BY, WHERE, INDEX и тп самому пилить?

Если у тебя БД будет метров на 300-500-1000-терабайт

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

Приведи пример, как ты сделаешь тоже что я привел выше с помощью одного запроса

Я просто храню всё списком. А где нужно, достаю его из БД и обрабатываю волшебным рекурсивным методом

сферический пример в вакууме намбо уан:
Есть каталог товаров. Нужно хранить/отображать(типа навигация, разворачивающийся список) структуру категорий.
Ну сколько их? Ну 300. Достал все из БД и строй дерево жабаскриптом на клиенте.
Не 300 а 5000000000? Ну подгружай по уровням. Да, нудно вводить понятие уровня, нумеровать их при переносе одной категории в другую и тп, но это всё дело не хитрое.


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

[Zend]

SELECT
дай_категории_первого_уров� �я_сука
FROM
каталог.категории
WHERE
подтяни_в_них_вложенные_кат егории_до_5-го_уровня_включительно
ORDER BY
сортани_все_уровни_по_алфав иту_сука
;

это конечно было бы здорово, но когда то нужно и мозгом думать

[Gozar]

сферический пример в вакууме намбо уан:
Есть каталог товаров. Нужно хранить/отображать(типа навигация, разворачивающийся список) структуру категорий.
Ну сколько их? Ну 300. Достал все из БД и строй дерево жабаскриптом на клиенте.
Не 300 а 5000000000? Ну подгружай по уровням. Да, нудно вводить понятие уровня, нумеровать их при переносе одной категории в другую и тп, но это всё дело не хитрое.

это конечно было бы здорово, но когда то нужно и мозгом думать

Я тебе сейчас опишу задачу, чтобы не пытаться разобрать твой бред.

Задача:

Есть БД пользователей, у пользователей есть чуть более чем 100500 разных характеристик, интересов и т.д. 
Имеем Пользователя с динамическим количеством 100500 параметров(каждый из это список ссылок на отдельную "таблицу" или "класс" или внутренняя ссылка на другое поле той же "таблицы").

Какие ещё динамические подгрузки, какие ещё категории?! Если ты не сможешь выбирать пользователя и связанно с ним подгружать выборки из этих 100500 параметров, то ты получишь ад. Самый натуральный, не выдуманный, а АДСКИЙ ад. Через 5-10 параметров, которые ты осилишь своими так называемыми списками ты получишь код работающий 1-2-3-10 секунд...

Даже если ты супер-пупер программист и проектировал 10 лет базы данных, а я их проектировал, т.к. у меня в мускуле аж 2 вида связей: списки смежности и граф на 5 внешних параметров.

Я не пишу на Postgree не потому, что мне взападло, а потому что она не может то, что мне нужно. Не умеет. Если умеет, то я тебя прошу покажи!

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

[Zend]

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

Скорее всего ты что то не так делаешь на этапе проектирования БД. БД она такая, прежде чем в неё что то сунуть нужно подумать о том как ты потом будешь это доставать.

или "класс"

ORM в хайлоад? фига! о_0

[Zend]

Кто не в теме, подумает что это не в тему, но мне почему то вспомнилось:

[Gozar]

Скорее всего ты что то не так делаешь на этапе проектирования БД. БД она такая, прежде чем в неё что то сунуть нужно подумать о том как ты потом будешь это доставать.

Скорее всего ты совсем не понимаешь о чём идет речь. Можешь сколько угодно думать как построить самолет с помощью лопаты и гвоздей. Из-за того, что ты будешь об этом думать самолет не построиться более правильно или быстро!