 |
|
Модераторы: LSD |
 
|
|
Хранение семантической сети в базе данных, Hibernate и семантическая сеть 
| Mikail |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 46 Регистрация: 24.12.2007 Репутация: нет Всего: нет |
Делаю тут социальную сеть с некоторыми дополнительными сущностями, кроме обычных (юзер, файл, картинка, комента, пост блога, группа) - проект и ресурс.
Решил свести все структуру базы данных к семантической сети. Вот схема:  ссылка на схему Синее поле - таблицы управления правами - для встроенного в веб-фреймворк инструментария управления правами. В перспективе можно и систему прав реализовать в форме семантической сети, но хочется скорее запустить проект, поэтому систему прав отложим на будущее. Розовое поле - сущности. В идеале сущность это поле бинарного или текстового формата и все. Но чтобы быстро приступить к работе думаю, можно основные сущности расписать в отдельных таблицах с несколькими полями. Зеленое поле - сама семантическая сеть. Таблица сущностей и таблица отношений между сущностями. К каждой сущности из таблицы entity надо добавить еще поле "тип" наверное. Получается, что все отношения между сущностями хранятся в семантической сети, а не в структуре отношений между таблицами. Насколько реальна такая схема? Какие у нее недостатки? Может быть семантическая сеть как-то иначе реализуется в базе данных? Как работать с этой схемой через ORM типа Hibernate? Может быть порекомендуете какой-нибудь проект посмотреть с открытыми исходниками (лучше на java или php), где грамотно реализована работа с семантической сетью? |
|||
|
||||
Загрузка ...
| Zloxa |
|
||||
 Чо?  Профиль Группа: Завсегдатай Сообщений: 3473 Регистрация: 12.9.2008 Репутация: 11 Всего: 161 |
Вполне реальна. В принципе все реально.
Сплошные - Рализация контроля целостности отношений триггерной либо процедурной логикой требует принудительного блокирования ресурсов, вплоть до захвата монопольного доступа к таблице. Простой пример: необходимо исключать возможность добавления связанной сущности в одной сессии при удалении мастер сущности в другой сессии, которая еще не видит незакоммиченных (недоинсерченных для dirty reads) данных. - Стоимость извлечения данных из системы увеличивается несоизмеримо уменьшению стоимости ее модернизации - Кажущаяся гибкость при проектировании, при реализации и эксплуатации превращается в стихийный геморрой и абсолютную непрозрачность. Тем не менее мое сугубое ИМХО в этом вопросе однозначно - через это надо пройти У Кайта - очень известной личности в Ораклином сообществе, как то спросили:"Каков был наихудший дизайн приложения, разработанный вами?" Он ответил Это сообщение отредактировал(а) Zloxa - 23.1.2009, 16:11 -------------------- Достоверно известно, что 89% людей доверяют статистике взятой с потолка  |
||||
|
|||||
|
|
| Правила форума "Общие вопросы по базам данных" | |
|
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.0461 ] [ Использовано запросов: 22 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |