я задумываюсь для почти таких же целей взять вместо Hibernate, Ibatis.. НО.. пока изучаю, и смотрю, что и как, и почему..   

Посмотрел(подсмотрел) на Ваш профиль. Исходя из собственного опыта - проблема в мировозрении.
Просто взгляд на вещи с разных строн. "Кривые" зеркала.

да конечно собственными, чьими же еще! имея 5 летний опыт разработки под СУБД оракл, кому как не мне понимать что оракл для конкретной задачи бесполезен. но волнует меня именно то, что автор даже не удасужился спросить о целесообразности его использования в соответсвующей ветке форума. и то что ни кто не обратил его внимание на это.


не знаю что конкретно вы имеете ввиду, но могу с уверенностью заявить, что самое узкое место любой системы это БД, вернее не грамотность в его использовании. конечно если текущую задачу "соц. сеть" развернуть на оракле и мега железе, то 99% проблем не возникнет, но вряд ли оно того стоит.


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



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


неоспоримый факт.


поясните плиз что за разные стороны о которых вы говорите и как они противоречат адекватности выбора технологий для конкретной задачи.


если я кого то обидел - прошу прощения.


пожалуйста.

где в той цитате хоть слово про Фаулера???  

ПС спецом для вас выделил ключевые слова ;)

Это сообщение отредактировал(а) seth - 25.9.2008, 09:47

Наверное также говорил и Гейтс...

да ни где, просто попытался на глупое утверждение дать глутый ответ... ;)


спасибо за заботу.

имхо у каждого своя голова на плечах - захотел спросил захотел не спросил - темболее имхо ветка Оракла это не последняя инстанция ;)


узким местом может быть что угодно - начиная от плохого канала, слабого железа, глючного сервера, глючной проги и заканчивая вашими любимыми СУБД 

Добавлено через 1 минуту и 34 секунды

лучше б вы сказали чем глупое утверждение а не глупо отвечали ;)

ПС темболее в последующих постах можно найти схожие с моими мысли у других собеседников ;)

Я не знаю, говорил ли так Гейтс.  



Это ну очень спорное заявление.  Ещё есть сериализация при сетевом обмене (например веб-сервисы), стратегии разграничения транзакции (уровни изоляции), конкурентное выполнение задач. Т.е. не только из одной БД системы состоят. Можно её (БД) затюнить "по самое не могу", но если веб-сервисы будут тормозить, то все старания пройдут даром.

Это сообщение отредактировал(а) powerOn - 25.9.2008, 10:11

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


если бы вы хотябы попытались вникнуть в суть дела, а не выхватывали удобные для вас куски цитат, то поняли бы что я хочу довести до ващего сведения.


примите во внимание что я себя не позиционирую как спеца по всем СУБД, будьте внимательнее.


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


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

А насколько удобно использовать хранимые процедуры для реализации бизнес-логики при работе с распределёнными базами данных?

DimW  нечего демагогию разводить: есть что сказать - все во внимании

вот еще инфа
Сравнение Hibernate (ORM) vs JDBC

И стал самым богатым человеком в мире...


Что-то не о том вы спорите...

Разрабатывая соц сеть, ГЛАВНОЕ, сделать ее интересной. 

Уверяю, что если соцсеть, написанная относительно нормальным PHP прогером с использованием какой-нибудь MySQL, загрузит среднестатистический сервер, хотя бы на 50%, уже будет приносить достаточно, что бы нанять группу профи, для создания нормального движка. 

На что стоит впервую очередь обратить внимание? 
- Идея
- Удобство использования
- дизайн
- продвижение проекта

Технологии вторичны.

Нужно применять то, что позволит наиболее быстро запустить проект, и наиболее просто наращивать его функционал.

Если пойти немного дальше - выбор технологий должен учитывать наличие квалифицированных специалистов на рынке труда.

Спасибо, обязательно посмотрю.

Vasay, для зарегистрированных, но вероятно, впоследствии будет добавлена поддержка openid и google authentication.
JSF мы пользоваться не будем, для AJAX скорее всего остановимся на применении jQuery. Те части сайта, которые должны будут индексироваться, будем делать с учётом SEO.


Честно говоря, с дизайном БД мы ещё не полностью определились, но думаю, что некоторая часть бизнес-логики, тесно связанная с информацией будет реализована на PL/SQL, для этого будем использовать инструменты Spring для работы с БД.


Видимо, Вы имели ввиду front end  Мы хотим, чтобы пользовательский интерфейс был как можно проще и "легче", при этом очень важна межплатформенность и кросс-браузерность. Вместе эти требования отметают некоторое количество RIA фреймворков. Однако я не исключаю того, что с усложнением системы появятся элементы интерфейса, которые будет эффективнее реализовать на одном из RIA фреймворков.


Дело вкуса - кому, что интереснее  Скажу по секрету, что есть особенности, которые с большой вероятностью обеспечат и коммерческий успех именно этого проекта ;)


Напротив, это меня очень заботит - теперь, когда я узнал, что Oracle - это версионник. Хотя я ещё не знаю, что это значит, но обязательно выясню 


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


Я, конечно, много раз слышал, что Oracle, это хорошо, но я не меньшее число раз слышал этот отзыв и о том же MySQL. Мой выбор обусловлен вовсе не этим, а тем, что я имею некоторый опыт работы с этой СУБД (хоть и не на высоком уровне, но кое-что понимаю), а так же наличием в команде человека, хорошо разбирающегося в PL/SQL. К тому же, как я уже писал выше в этом посте, часть бизнес-логики будет расположена именно в СУБД в виде пакетов процедур и функций.


Не популярных, а интересных. Те технологии, которые я обозначил интересны мне не потому что популярны, а потому что я почитал о них, в некоторые уже начал вникать поглубже и они мне понравились/заинтересовали. Хотя не спорю, что изначально обратил на них внимание вследствие популярности, иначе я бы просто не узнал о существовании некоторых из них.


Если не сложно, поделитесь результатами своих изысканий. Хотя я и не упомянул его в первом посте Ibatis меня тоже заинтересовал.


Само собой, сначала мы обдумали этот вопрос, а потом уже принялись выбирать технологии 


Вот сейчас и настала их вторая очередь - после того, как оформились идеи и концепции будущего проекта ;)


Не удосужился - это немного некорректно сказано. Просто выбор я уже сделал, основываясь на своём опыте и опыте своих друзей и знакомых. Но если Вы или кто-нибудь другой аргументированно объясните преимущества для данного проекта какой-либо другой СУБД или хотя бы недостатки Oracle, то свой выбор я изменю.

PS: Всем большое спасибо за дискуссию, читал с интересном и жду продолжения. Стараюсь, по мере сил, учесть все замечания и мнения.

Я говорил лишь разве что о противоречиях человеческих предпочтений.. То что мы лучше всего знаем, то и "толкаем".
Всё это к теме не относится и все споры не о чём (всмысле они вне темы топика - если интересно - можно создать тему в более соответствующем разделе форума), но я думаю Вы почувствовали напряжённость сообщений.
Ну и напоследок.. База данных выбрана, как бы там ни было. А выбор технологии доступа к данным вообще не должен ставиться, нужно выбирать наиболее востребованные, технологичные и гибкие инструменты,  (Hibernate и(или) JPA). В конце концов база - это только хранилище данных, в контексте задачи, а гланое - веб-приложение (не думаю, что потребуется сильно навороченая схема данных), поэтому лучше изначально всё строить "правильно" как принято.

DimW, Том Кайт написал хорошую книгу для СВОЕГО круга, но это не Библия. Хотя на неё молятся. И база данных - это не панацея. Это и есть разные "мировозрения" - молящиеся на Тома и др., как-то перебивающиеся без него. Не нужно впадать в крайности. Если есть вопрос по оправданости использования ORM - я создам отдельную ветку, чтобы захватить его во всей широте !..   
Обсуждение

сорри действительно фронт энд 



ну это было мое маленькое имхо   если вам интересно то я только за 

я вот тоже для фейсбука думаю приложение написать 



вообще технология популярная ведь не потому что кто то сказал что это популярно и все подхватили - а скорее потому что она интересная или обладает некими существенными плюсами или отсутствием альтернатив ;)