- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
не надо эти фреймворки. Сделай так чтоб сайт неговноконтентом автонаполнялся. Вообще цены тебе не будет ))
Вы понимаете разницу между "вшить в архитектуру 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 и более таблицам, как избавиться от джойнов? :)
Это только в простых хоумпаджах все легко.
Отвратительная статья.
Как в фреймворке может быть админка? Управлять чем, собственно??
Остальное тоже - отсутствие логики сказывается