Mainframe_старыйдля высоконагруженных сайтов есть механизм кэширования и вот тут уже все равно, какая модель в основе, однозначно удобнее гибкая модель. Правильно я вас понял, что для любого сайта подойдёт сколь угодно слабый сервер БД?

Точнее, вы выразились несколько иначе - чем более высоконагруженный сайт, тем слабее нужен сервер БД.
MasterZivпри использовании EAV JOIN-ов гораздо больше в запросах.
(за это его и не любят). При обычной реляционной модели JOIN-ов в запросах
порядка числа таблиц, при использовании EAV -- JOIN-ов порядка числа атрибутов.По моему, подход ключ-значение не тождественен EAV (хотя у них и есть что-то общее).
Под "значение" в случае key-value БД подразумевается не одиночный атрибут, а запись (или объект).

Mainframe_старыйэто вы так выразились, а не я. я выразилась, что скорость работы с базой данных может никак не влиять на работу с сайтом пользователей.А, ну с такой формулировкой я согласен. На практике, однако, (и в известных существующих проектах "высоконагруженных сайтов") на субд ложится большая нагрузка, и ни один из них не строится по модели EAV (про крайней мере, мне такие неизвестны, поделитесь, если знаете).

И даже теоретически на СУБД не может быть маленькой нагрузки, если есть много операций записи. Просто в EAV количество операций записи будет больше, тут ничего не поделать.

Mainframe_старыйвопрос гибкости приобретает значимость, равную 1.Не вижу каких то преимуществ по гибкости у EAV.

Во всех случаях нужно проектировать модель данных по бизнес модели. Только для EAV используется один синтаксис определения сущностей, атрибутов, констрейнов, и прочего, для SQL другой. Только и всего.

Mainframe_старыйизвестные не знаю, наша собственная cms строится поверх нашей суэд, которая строится поверх нашей системы управления понятиями , которая основана на описании понятий и отношений и ограничений и физически все это на варианте eav.
сайты работают с обычной для статических сайтов скоростью. число записей в eav несколько миллионов.Число новых записей в eav несколько миллионов за какое время, не понял? Или всего?
Если всего, то и в екселе можно хранить, при наличии кеширования.

ТС писал про:
kastolomтак много слышал, что высоконагруженные сайты, типа вконтакте да фейсбук , не юзают join-овДля таких не подойдёт.

У меня на предыдущей работе в базе для сайта было несколько сотен млн записей, и новых тысячи в секунду. С EAV моделью пришлось бы сильно увеличить количество серверов :-(

Mainframe_старыйстроится поверх нашей системы управления понятиями , которая основана на описании понятий и отношений и ограничений и физически все это на варианте eavИ я всё таки не понимаю, чем собственная система "описании понятий и отношений и ограничений" лучьше, чем прелдлагаемая производителем СУБД. Её освоить проще, программировать быстрее, там более удобный язык?

ViPRosсобственная богачеХорошо, если так :-)

Mainframe_старыйя вам сразу сказала, что модель базы для производительности сайтов значения не имеет. можете и на экселе, ежели вам с ним удобнее. нам удобнее eav на реляционной основе.А я сразу сказал, что имеет. Вместо 10 серверов потребуется сотня.
А на екселе несколько тысяч.

Я же тоже про свой опыт говорю.

Просто у вас сайты не нагруженные.

Mainframe_старыйalexeyvgПросто у вас сайты не нагруженные.

видимо, вы просто не умеете их готовить. в статических сайтах БД не имеет значения. она важна только там, где нет кэширования страниц или в вопросах формирования контента вручную. Ну речь то не о статических сайтах.

Пользователи заводят контент, его же нельхзя всё время держать в кеше и не сохранять.

Само собой, подразумевается, что вся статическая инфа закеширована.

Одно из двух:Mainframe_старыйу нас вообще нет статикиMainframe_старыйтем не менее весь сайт статический
:-)
Mainframe_старыйСайт может вообще не иметь статической информации, но при этом весь быть закэшированным.Ну при чём тут это?

Странно, что вы спорите с простым тезисом:
Если пользователь вводит информацию, то её нужно сохранить.

Ну и второй тезис тоже несложен:
Много сохранений - большая нагрузка на СУБД.