LINUX.ORG.RU

[WEB] Архитектура баз данных

 


0

0

Никогда особо не увлекался базами данных, а тут приспичило, причем по работе. Надо создать портал для организации с элементами социальных сетей. С первого взгляда спроэктировать БД не трудно, но есть опасение, что могу спороть чушь. Либо медленно, либо не масштабируемо, либо что-то еще. Поэтому хотелось бы спросить у более опытных коллег, чтобы в последствии не наступить на грабли:

1. Есть ли информация, которую бы стоило почитать? (гуглил, не нашел)

2. Если есть какой-то личный опыт или советы - буду рад выслушать =)


premature optimization is the root of all evil

соцсети сложны своей логикой и огромным количеством связей.

так что сделай сначала дико тормозящую бету с использованием ОРМ. а потом уже оптимизируй. нет времени? а его никогда нет.

Pi ★★★★★
()
Ответ на: комментарий от Pi

> premature optimization is the root of all evil

Не всегда так. Кое какие элементарные связи можно продумать заранее, а так же стоит заранее заложить возможность таки масштабируемости.

А если забубенить одну таблицу с over 9000 полей, то это приведёт к переделке всего проекта from scratch.

Anoxemian ★★★★★
()

приличный какой ORM в зубья и оперировать на уровне объектов

hizel ★★★★★
()
Ответ на: комментарий от Anoxemian

>А если забубенить одну таблицу с over 9000 полей, то это приведёт к переделке всего проекта from scratch.

это вопрос эстетики:если тебя не коробит наличиe 9000 полей, то что-то менять надо в консерватории

Pi ★★★★★
()
Ответ на: комментарий от Pi

> соцсети сложны своей логикой и огромным количеством связей.

А вот логика там напрочь отсутсвует. Есть объект (группа, картинка, юзер, ролик) и отношение между объектами - от какого объекта, к какому объекту, тип отношения, например "содержит", "является владельцем", "является другом", "является недругом", "проплюсовал", "проминусовал". Классическая структура связей, используемая в "накопительных" системах.

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

Причем наибольшую проблему в системе вызвал не поиск, а ввод информации :-)

no-dashi ★★★★★
()
Ответ на: комментарий от thevery

> http://www.insight-it.ru/, а именно http://www.insight-it.ru/category/net/scalability/

почитать интересно, но так и не нашел ответы на пару вопросов, а именно:

Априори будем считать, что все знаюттакую соц. сеть как "ВКонтакте" и ей подобные.

Как там хранятся все изображения? в одной таблице для всех пользователей с указанием хозяина или как-то иначе? Как смотрится со стороны "правильности" и "ТРУЪ" такой вариант? не будет ли большого оверхеда по времени при INSERT INTO, SELECT? Или, если нет - как лучше реализовать?

Заранее спасибо.

irq
() автор топика

Спроектировать БД не трудно, если известно, какой функционал необходимо автоматизировать.

Примерно так

Функционал -> Алгоритмы -> БД -> Оптимизация скорости

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

sign
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.