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

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

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

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

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']
}

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

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

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

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

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

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

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



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


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

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

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

Задача:

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

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

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

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

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

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

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

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

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