|
0 Всего найдено: 80
tivix
Сообщение
12/01/2013 12:43
Копия темы
Друзья как правильно написать условие php в БД хранится время в time(), как создать правильно условие - если сегодня прошло 7 дней от даты в БД, то делается то то...
venuko
Сообщение
12/01/2013 12:54
Копия темы
:) так и не нашли программиста значит Сообщество есть, лучше там задать такой вопрос.
zelenin_av
Сообщение
12/01/2013 12:55
Копия темы
// получаем из базы значение $time if ( $time < ( time() – 7 * 24 * 60 *60 ) ) { // что-то делаем, если прошло 7 дней от даты в БД }
1site
Сообщение
12/01/2013 12:56
Копия темы
select * from table where date_add(TIME_COLUMN, DAY, 7) >= now А потом свое PHP
zelenin_av
Сообщение
12/01/2013 13:10
Копия темы
а зачем выборка данных таким образом? никто не говорил, что другие данные не нужно обрабатывать. Например, выводятся все посты, но у тех, что написаны больше недели назад, должен быть другой цвет заголовка.
1site
Сообщение
12/01/2013 13:14
Копия темы
Конечно. И ваш и мои варианты верны, так как зависят от задачи. Если надо цвета, то ваш вариант предпочтительнее.
zelenin_av
Сообщение
12/01/2013 13:16
Копия темы
нет, ваш вариант не правильный, так как не удовлятворяет поставленной задаче.
1site
Сообщение
12/01/2013 13:29
Копия темы
PHP не компилятор, больше лишнего – дольше обработка. Пара скобок лишняя. Но не будем цепляться к мелочам.
zelenin_av
Сообщение
12/01/2013 13:34
Копия темы
все верно говорите. Только неверный запрос в БД – это в тысячу раз больше потраченного процессорного времени, чем дополнительные скобки. ) немножко троллинга программистов – немножко хорошего настроения )
1site
Сообщение
12/01/2013 13:39
Копия темы
С чего бы он неверный. Вы сами придумали на счет цветов. По опыту, человек скорее всего хотел сделать выборку по базе, потом сравнивать даты и "что-то делать" как написано. Основываясь на этом запрос, впрочем там не хватает приведения типа в колонке, но я посчитал что это неважно. Да в целом это не соответствует тому, что он спрашивал, но если я прав, то с вашим кодом как раз нагрузка на процессор будет в разы сильнее.
PallasKatze
Сообщение
12/01/2013 13:47
Копия темы
> С чего бы он неверный Потому что DATE_ADD() во WHERE приведёт к фуллскану таблицы с лишними вычислениями, индексы не будут использованы, что при миллионах строк положит БД надолго. Дату нужно один раз вычислить в PHP, а потом просто сравнивать её с полем таблицы.
1site
Сообщение
12/01/2013 13:50
Копия темы
Да, лучше сделать TIME_COLUMN <= date_add(now, DAY, -7) так будет дата вычислена один раз. Индексы будут использованы. На счет дату вычислять PHP это бредятина.
1site
Сообщение
12/01/2013 14:11
Копия темы
Фигню пишете, я уже писал про приведение типов. Если вы напишите, TIME_COLUMN <= UNIX_TIMESTAMP(date_add(now, DAY, -7)) все будет ок. The server interprets date as a value in the current time zone and converts it to an internal value in UTC. Читайте доки по mysql, время будет переведено в UTC с учетом смещения.
PallasKatze
Сообщение
12/01/2013 14:31
Копия темы
Так лучше, да. > На счет дату вычислять PHP это бредятина. Напомню вам, что горизонтально масштабировать серверы приложений гораздо проще, чем серверы БД. Поэтому от вычислений в SQL-запросах, если ожидается значительная нагрузка, лучше отказаться.
1site
Сообщение
12/01/2013 14:36
Копия темы
Напомню, что логику работы с данными лучше выносить в сервер, работающий с данными. И, да stored procedure лучше, чем php function с точки зрения логики. И, кстати масштабировать сервер СУБД проще, чем сервер приложений, хотя бы потому что есть встроенные инструменты репликаций. Это всего лишь ваши придирки и врядли они интересны ТС.
1site
Сообщение
12/01/2013 14:51
Копия темы
Не говорите ерунды, я уже написал про приведение типов, я его просто опустил. PS. SELECT DATE_SUB(NOW(), INTERVAL 7 DAY) <> UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 7 DAY)); К чему это неясно, я и не утверждал что так и есть. Это вы утверждали про UTC/
zelenin_av
Сообщение
12/01/2013 15:08
Копия темы
неверный с того, что он не соттветствует поставленной задаче. нагрузка будет минимальна, если time() занести в переменную
PallasKatze
Сообщение
12/01/2013 15:10
Копия темы
> логику работы с данными лучше выносить в сервер, работающий с данными Нет, логику работы с данными выносят в модель, а не в СУБД. > stored procedure лучше, чем php function Чем? > масштабировать сервер СУБД проще, чем сервер приложений А для масштабирования серверов приложений нужен просто новый сервер с установленным приложением, без усложнений вроде репликаций и сопутствующих рисков, вроде кратковременной рассинхронизации слейвов с мастером и проблем с производительностью при частом изменении данных на мастере.
1site
Сообщение
12/01/2013 15:10
Копия темы
Не только CAST и конверт. Например, MONTH() осуществит преобразование типов, хотя это функция. В данном моменте тоже было приведение типов из Datetime в Unix timestamp. Хотя на низком уровне это и может быть INT, но имелось ввиду логическое приведение типов. Да вы и сами это понимаете, просто не знали что UNIX_TIMESTAMP учитывает смещение.
1site
Сообщение
12/01/2013 15:11
Копия темы
> Чем? Тем что логика для работы с данными в одном месте.
PallasKatze
Сообщение
12/01/2013 15:12
Копия темы
Читайте, пожалуйста, профильные ресурсы, где люди делятся своим опытом и таких вопросов не будет. Не стесняйтесь гуглить, в т.ч. англоязычные статьи.
1site
Сообщение
12/01/2013 15:14
Копия темы
Читайте, пожалуйста, профильные ресурсы и вы поймете как важно отделять логику в крупных приложениях. Почитайте почему так хорош Oracle, где вся логика работы с данными в хранимых процедурах. Не смотрите дальше плоских табличек mysql. Кстати, спасибо за совет, я как раз читаю.
1site
Сообщение
12/01/2013 15:18
Копия темы
> Ресурсы MySQL ограничены, скажем, количеством транзакций в секунду. Так же как и ресурсы веб-сервера. > Для горизонтального масштабирования приложения нужно взять еще один сервер и парой команд развернуть приложение. Помимо этого понадобится доп ПО, например балансер. Не забывайте, что у вас в приложении несколько уровней. Помимо PHP еще и веб-сервер и сопутствующие сервисы. наверняка если крупный проект это какие-то демоны и тд.
PallasKatze
Сообщение
12/01/2013 15:19
Копия темы
А в коде вы с данными не работаете? Вы путаете роли компонентов системы. СУБД должна хранить данные, обеспечивать их целостность и оптимальное выполнение запросов, а не делать работу модели приложения, перемалывая числа/строки, используя ограниченные возможности (и не имея возможности их расширения) и ограниченный синтаксис.
1site
Сообщение
12/01/2013 15:20
Копия темы
> MONTH не преобразует тип Вход один тип, выход другой тип. Как бы вы не спорили, тип преобразуется в другой) > Я прекрасно знаю, что делает UNIX_TIMESTAMP Я рад, странно почему вы тогда не знали о UTC
1site
Сообщение
12/01/2013 15:25
Копия темы
Откомпилированный код mysql и выполняется быстрее и снижает нагрузку на передачу данных, даже если у вас локально через unix сокет. Вообще всегда код mysql оптимальнее, чем код с данными в php, через все эти сокеты, драйверы и т.д. Это очевидно. Правда я не понимаю, почему мы об этом говорим)
1site
Сообщение
12/01/2013 15:28
Копия темы
> А вот хранилище данных всегда было и остается узким местом при росте нагрузки. Почему же. Вы меня не убедили. Все современные СУБД имеют инструменты серверной репликации. В PHP (не как язык, а как набор инструментов) есть такой инструментарий?
PallasKatze
Сообщение
12/01/2013 15:30
Копия темы
> Помимо этого понадобится доп ПО Если админ — молодец, то это ставится из заготовленных пакетов уже с нужными конфигами парой команд. > например балансер Эка проблема. Один балансер может обслуживать много серверов приложений, а его развёртывание — довольно тривиально. Не хотите балансирование через реверс-прокси — можно использовать несколько Round-Robin DNS-серверов, на них нагрузка ещё меньше.
1site
Сообщение
12/01/2013 15:32
Копия темы
Подумайте логически при репликации что будет быстрее. Если данные идут в PHP по локальной сети через драйвер, как есть, а потом обрабатываются. Или сначала идет обработка, потом они уже идут в ваш сервер приложений. Вам любой новичок ответит на этот вопрос. А вы спорите) Я думаю это очевидно для всех. Само собой пока у вас все локально вы можете писать работу с данными где угодно.
1site
Сообщение
12/01/2013 15:35
Копия темы
> По этой логике практически любая функция является приведением типов. Не вижу проблем. По ссылке: Приведе́ние ти́па (type conversion) — преобразование значения переменной одного типа в значение другого типа. Да, я не вижу разногласий. В конце концов тип привелся в другой тип помимо операции вычисления. > Здесь у меня сломался мозг. Не парьтесь, я уже сам не знаю, знали бы вы об этом или просто решили попридираться над кодом, написанным менее, чем за минуту для примера))
PallasKatze
Сообщение
12/01/2013 15:40
Копия темы
> Откомпилированный код mysql и выполняется быстрее Ставите кэшер байт-кода на свой любимый язык и ок. К тому же я не уверен, что при использовании хранимых процедур используется кэш запросов в нужной мере. > через все эти сокеты, драйверы и т.д. Оверхед сети незначителен, если серверы находятся в одном датацентре, тем более, что можно сэкономить время на коннект, используя персистентные подключения. А ставить в серьёзном проекте СУБД на сервер приложений — это не комильфо и повод задуматься о своей компетенции. > снижает нагрузку на передачу данных Между сервером СУБД и сервером приложений может лежать оптоволокно на десяток гигабит. Проблема не в передаче данных, а в процессорном времени и нагрузке на диск.
1site
Сообщение
12/01/2013 15:41
Копия темы
> Как говорится, "я с вами не спорю, а говорю то, как оно есть на самом деле". На самом деле не так как вы говорите. Скомпилированнй код mysql быстрее, чем передача данных необработанных (даже через unix-сокеты), потом обработка PHP. В 99% случаях. > И эта репликация имеет конечные пределы производительности, в отличии от. Скажите это промышленным СУБД, в Oracle напишите. Скажите, что вам не хватает мощности инструментов их СУБД для вашего проекта)
1site
Сообщение
12/01/2013 15:42
Копия темы
Извините бред полный. Пред обработка данных на сервере СУБД это стандарт уже. Вы может не верить в это, ваше дело же) > Сервер баз данных хорошо занимается выборкой и хранением данных, сервер приложений хорошо может обрабатывать данные Надеюсь вы никогда не будете проектировать очень крупный проект.
PallasKatze
Сообщение
12/01/2013 15:43
Копия темы
> и вы поймете как важно отделять логику в крупных приложениях Я отделяю логику в модель в любых приложениях, не нужно грязных инсинуаций) > почему так хорош Oracle, где вся логика работы с данными в хранимых процедурах Это проблемы Оракла. В конце концов, она не навязывает разработчику именно использование хранимой логики.
1site
Сообщение
12/01/2013 15:45
Копия темы
> К тому же я не уверен, что при использовании хранимых процедур используется кэш запросов в нужной мере. А зря > А ставить в серьёзном проекте СУБД на сервер приложений — это не комильфо и повод задуматься о своей компетенции. А я ставил? Откуда вы это придумали? > Между сервером СУБД и сервером приложений может лежать оптоволокно на десяток гигабит. Извините, но вы продолжаете строить сферического коня в вакууме, где Php быстрее данные обрабатывает чем СУБД.
PallasKatze
Сообщение
12/01/2013 15:47
Копия темы
О, кстати, а что вы скажете о такой важной вещи, как "переносимость между СУБД"? Прикажете переписывать кучу хранимых процедур при миграции с MySQL на PostgreSQL, например?
1site
Сообщение
12/01/2013 15:47
Копия темы
> Это проблемы Оракла. Кстати я не думаю что это проблема Оракла. Это как раз ваша проблема, что вы не используете всю мощь СУБД, такую как пред обработка данных, например хранимки. А пишите тонну PHP кода для этого. То что вы не осилили синтаксис хранимок не значит что они "проблема этой СУБД" и не нужны...
1site
Сообщение
12/01/2013 15:48
Копия темы
А вы не рассказали о переносимости кода. Как переносимость с PHP на Python. Легко, когда логика работы с данными у вас в СУБД.
PallasKatze
Сообщение
12/01/2013 15:52
Копия темы
> А зря Что зря? Результат выполнения хранимой процедуры сохраняется в кэше? Или может быть, вы из СУБД можете положить этот результат в in-memory хранилище? > А я ставил? Откуда вы это придумали? Я это не придумал, это общепринятая практика. При большой нагрузке СУБД и приложение будут драться за ресурсы одного и того же сервера. > вы продолжаете строить сферического коня в вакууме Да какого я коня строю, о чём вы вообще? Вы так говорите, будто я предлагаю передавать в приложение всю таблицу и там её перелопачивать.
1site
Сообщение
12/01/2013 15:56
Копия темы
> Или может быть, вы из СУБД можете положить этот результат в in-memory хранилище? Конечно можно. Не напрямую конечно в Mysql. А оракл вообще умеет тот же Memcached. > Вы так говорите, будто я предлагаю передавать в приложение всю таблицу и там её перелопачивать. примерно так и есть.
PallasKatze
Сообщение
12/01/2013 15:58
Копия темы
На смену языка в уже написанном проекте решаются крайне редко, а решают менять СУБД ради плюшек — достаточно часто. > Легко, когда логика работы с данными у вас в СУБД Нифига не легко. У различных СУБД есть специфика в реализация SQL, я молчу про хранимые процедуры. А при наличии грамотной модели — я просто меняю СУБД и, возможно, корректирую пару строк кода.
1site
Сообщение
12/01/2013 15:59
Копия темы
> математика А при чем тут данные СУБД? Математика это пожалуйста в сервер приложений. Вы постоянно путаете теплое с мягким. В СУБД делайте то что связано с данными, а мат функции оставьте для питона. Никто вас не заставляет построить все приложения в Mysql. Правда опять-таки в оракле это уже нормально.
1site
Сообщение
12/01/2013 16:00
Копия темы
> На смену языка в уже написанном проекте решаются крайне редко Ну почему от PHP часто отказываются, когда проект вырос)
1site
Сообщение
12/01/2013 16:06
Копия темы
Извините я не хотел обидеть вас. Ну например, я работал с биллингом сотовых операторов. Вся логика само собой в хранимках, подумать что это бы делал какой-то там PHP просто дико. Скажите им, что все должно обрабатываться в PHP. Второй пример, я работал в крупной национальной компании. Вся экономика, вся логика, все в хранимках. Подумать о том, что там был бы какой-то PHP дико. На сайтах конечно совсем по-другому. Часто лепят все в PHP, всю логику для работы с данными, потом мучаются, конечно, если проект растет, переписывают... PS.Кстати вы приводили бухгалтерию там еще и еще поехидничали что я выделил математику. Бухгалтерия тоже вся логика, все в СУБД, никаких PHP расчетов. Это было бы просто смешно.
1site
Сообщение
12/01/2013 16:15
Копия темы
Вот когда вы поработаете с такими объемами данных, в таких проектах. Вы поймете, что логика приложения для работы с данными в крупных проектах это только СУБД. Боже упаси как-то там PHP использовать для логики. PHP и всякие там WinForms с Java только для отображения данных и вывода отчетов.
PallasKatze
Сообщение
12/01/2013 16:19
Копия темы
> Ну почему от PHP часто отказываются, когда проект вырос) А чего вы добиваетесь проводя эту аналогию? Пытаетесь доказать, что часть приложения, написанную на хранимых процедурах не нужно будет переписывать? Так нет же, мы не об этом, а о том, что на хранилище не должно быть лишней логики по причинам, указанным выше.
PallasKatze
Сообщение
12/01/2013 16:25
Копия темы
Если вы таки работали с такими штуками, то должны понимать разницу между Oracle и MySQL, которую мы обсуждаем. Oracle — это энтерпрайз решение и имеет достаточный функционал для написания именно полноценных приложений под себя, а не "хранимых процедур" в том смысле, который употребляется в их отношении в MySQL.
PallasKatze
Сообщение
12/01/2013 16:28
Копия темы
Алсо, PHP в биллинге сотовых операторов — это действительно дико, бо он далёк от энтепрайз-уровня по многих показателям.
1site
Сообщение
12/01/2013 16:31
Копия темы
> но это оракл и это не веб Ошибаетесь, много крупных сайтов с использованием оного. > Теперь попробуйте то же самое реализовать на MySQL или Postgres Ну Postgres вполне себе. И я думаю что-то серьезное он потянет. Само собой Mysql это ерунда.
1site
Сообщение
12/01/2013 16:33
Копия темы
А как же вопли, что логика на СУБД это дикость, СУБД только для хранения данных (видел тут такой бред) и все должен обрабатывать PHP) Наконец-то вы со мной согласились. Но наверное вы еще только не поняли что крупный (действительно крупный со своей логикой, а не просто миллионы записей) сайт это то же самое.
PallasKatze
Сообщение
12/01/2013 17:13
Копия темы
Нет, я с вами не согласился: http://www.free-lance... Логика в СУБД — это по-прежнему дикость. Но вы отказываетесь видеть, что Oracle из себя представляет не только хранилище данных, но и своеобразный сервер приложений, в отличие от MySQL и ей подобных.
1site
Сообщение
12/01/2013 17:20
Копия темы
Да пишите кашу на PHP, желательно вперемежку с HTML, зачем вообще логику отделять. Ваше дело, вы же думаете хранимки это просто так придумали для дураков. PHP лучше, желательно и where в select не использовать, ведь доп нагрузка на сервер БД, что непримлемо, PHP сам все обработает, по вашей логике. Вообщем шутки шутками, но серьезную систему надеюсь вы не будете так проектировать, как тут пишите. Оракл – сервер БД, сервер приложений там тоже есть, но он никак не связан с хранимками, он для PHP и джава. Это совсем другое.
PallasKatze
Сообщение
12/01/2013 17:30
Копия темы
Я вообще на Ruby перешёл, что вы со своим PHP привязались? Мне ничего не мешает отделять логику в коде, а вы сравниваете тёплое с мягким и я таки тоже надеюсь, что к проектированию архитектуры критичных высоконагруженных приложений вас не допустят на дистанцию пушечного выстрела, бо после таких горе-разработчиков-максималистов, которые в упор не видят разницы между MySQL и Oracle, нормальные люди тратят свои нервные клетки и бешеные бабки на доработку тормозящих, со скрипом масштабируемых систем.
1site
Сообщение
12/01/2013 17:37
Копия темы
0
> я таки тоже надеюсь, что к проектированию архитектуры критичных высоконагруженных приложений вас не допустят на дистанцию пушечного выстрела Потому что stored procedures по мнению Александра зло. Ни в коем случае их нельзя использовать) Не обещаю, что прислушаюсь к вашему авторитетному мнению, ведь все авторитеты, кроме вас, считают что вынести логику работы с данными в СУБД это правильно. |
|
Выразить восторг, поругаться или предложить что-нибудь можно на форуме |
Для обсуждения этого сервиса так же есть темы на фрилансе по поиску , флудотопу ,и по удалённым сообщениям ,и по Актуальным/популярным темам , и по топу "кто кому больше наотвечал" |