- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
не надо эти фреймворки. Сделай так чтоб сайт неговноконтентом автонаполнялся. Вообще цены тебе не будет ))
Вы понимаете разницу между "вшить в архитектуру foreign key" - как мы сказали... и между "использовать foreign key" - как написали Вы?
Я вообще вашей первой части не понимаю. foreign key относится к модели базы, например: "аккаунт -> статья -> комментарий" или "товар -> фотография". Миллионы различных вариантов, все зависит от желания разработчика.
Нельзя завязывать приложение/архитектуру на джоинах и прочем. Ибо разделяй и властвуй.
Всегда должна быть возможность, при этом не сильно потеряв в производительности, работать с базовым набором данных "одиночными" выборками.
При чем тут архитектура если выборкой должен ORM заниматься. И от реализации этого ORM и будет зависеть, JOIN там или SELECT.
Я вообще вашей первой части не понимаю.
Так, а в чем смысл возражать тогда? Если не понимаете.
foreign key относится к модели базы, например: "аккаунт -> статья -> комментарий" или "товар -> фотография".
А модель базы чем диктуется? Правильно, архитектурой. А что нельзя завязывать на форежн? Правильно, архитектуру.
При чем тут архитектура если выборкой должен ORM заниматься. И от реализации этого ORM и будет зависеть, JOIN там или SELECT.
В "абстрактном сферическом фреймворке в вакууме" - да.
Мы же говорили об архитектуре заточенной на конкретную задачу.
Даже писали "Правильные запросы можно создать только правильно зная задачу. Поэтому эта дилемма (прим: попытка создать правильный ORM для всего всего) в рамках общего фреймворка/цмс неразрешима. ".
Попробуем перефразировать.
Если Вы делаете приложение, которое "как-то" должно оформить запросы в базу, получив "что-то" на входе, то Вы можете реализовать джоины, прямые запросы, форежн ключи и прочее - как Вам б-г на душу положит. Nobody cares.
Если Вы делаете приложение, которое должно быстро работать и хорошо масштабироваться, то его цели будут напрямую влиять на архитектуру и на реализацию каждого конкретного запроса и тут уже абстрактным ORM, которое "как-то" оформит запросы в базу не обойдетесь. Каждую группу запросов, если не каждый запрос, Вам придется оформлять по индивидуальной схеме, в ряде случаев руководствуясь не только теорией о скорости, но и практическими тестами. Вспомните, например, для чего делают денормализацию БД - а ведь это самые первые полшага на этом пути.
Лучшее что может разрешить фреймворк в этом смысле, это создать логированный полуофициальный черный ход в обход своего встроенного ORM. Иначе в специализированных задачах он будет бесполезен.
Если Вы делаете приложение, которое должно быстро работать и хорошо масштабироваться, то его цели будут напрямую влиять на архитектуру и на реализацию каждого конкретного запроса и тут уже абстрактным ORM, которое "как-то" оформит запросы в базу не обойдетесь. Каждую группу запросов, если не каждый запрос, Вам придется оформлять по индивидуальной схеме, в ряде случаев руководствуясь не только теорией о скорости, но и практическими тестами. Вспомните, например, для чего делают денормализацию БД - а ведь это самые первые полшага на этом пути.
Большинство проектов в Интернете простые и низконагруженные. А для сложных проектов, мне кажется, лучше делать индивидуальный фреймворк (если миллионная посещаемость).
А для сложных проектов, мне кажется, лучше делать индивидуальный фреймворк (если миллионная посещаемость).
Или допиливать имеющиеся. Что будет наверное дешевле.
А модель базы чем диктуется? Правильно, архитектурой. А что нельзя завязывать на форежн? Правильно, архитектуру.
Это сейчас тролинг такой или же вы на полном серьезе это говорите ?
Какая цель?
Чем Laravel не подходит?
Вот список недостатков фреймворков:
http://blog.kpitv.net/article/frameworks-1/
П.С.
А если условие по 2 и более таблицам, как избавиться от джойнов? :)
Это только в простых хоумпаджах все легко.
А если условие по 2 и более таблицам, как избавиться от джойнов?
а нафига от них избавляться ? Ну грубо говоря
$rs = post->get->last()
for ($author in $rs) {
$last_post = $author->last_post();
print "{$author->name}: {$last_post->title}"
}
# любителям JOIN
$rs = post->get->last()->related('author');
for ($row in $rs) {
print "{$row->author->name}: {$row->title}";
}
А к недостаткам фреймворка можно отнести следующее "требование изучать обертку над языком программирования". В недостатках же по ссылке - полная путаница между фреймворком и cms.
Вот список недостатков фреймворков:
http://blog.kpitv.net/article/frameworks-1/
П.С.
А если условие по 2 и более таблицам, как избавиться от джойнов? :)
Это только в простых хоумпаджах все легко.
Отвратительная статья.
Как в фреймворке может быть админка? Управлять чем, собственно??
Остальное тоже - отсутствие логики сказывается