Сергей К.
1649 сообщений
#12 лет назад
Цитата ("uniq-ip"):
WebDesignStudio, в любом случае перебор таблицы в СУБД будет быстрее, чем при помощи скрипта. А эксперимент проведите, чтобы в этом не только качественно, но и количественно убедиться

все зависит от ситуации. Я считаю что в этой конкретной ситуации лучше на стороне скрипта делать.

Вы мне так и не дали пример.
Андрей Халецкий
3562 сообщения
#12 лет назад
uniq-ip, Цитата ("uniq-ip"):
Вы предлагаете передать эти данные скрипту, на что уйдет время и дополнительные ресурсы API - и это будет работать быстрее по-Вашему?
Или Вы хотите выкинуть из цепочки СУБД и сделать так, чтобы скрипт обращался напрямую к файлам таблицы: индексному файлу, файлу данных и т.п. Если нет, то о чем спор?
Попробуйте читать тему. Я четвертый раз пишу что если данных много - то экономия по скорости будет существенная, если данных не много - то лучше делать в скрипте т.к. это наглядное/простое в поддержке/более гибкое решение.

Самое главное: смотреть на конкретную задачу, весьма вероятно что нужные результаты можно получить другим путем, т.к. этот вариант очевидно затратен. Для этого нужно знать немного больше чем дано. Если вас спрашивают каким концом микроскопа лучше забить гвоздь - стоит сначала убедится что молоток использовать никак нельзя. В процессе может выяснится что ремонтировать шурупами резиновые сапоги в принципе плохая идея.
Андрей Халецкий
3562 сообщения
#12 лет назад
Цитата ("WebDesignStudio"):
Вы мне так и не дали пример.
Пример придумать очень просто, вот первая идея. В таблице хранится посекундное изменение показателя (скажем цены акции) нужно найти самы длительный период непрерывного роста.
Сергей К.
1649 сообщений
#12 лет назад
Цитата ("SmartDesign"):
Пример придумать очень просто, вот первая идея. В таблице хранится посекундное изменение показателя (скажем цены акции) нужно найти самы длительный период непрерывного роста.

это не совсем правильная логика БД, лучше хранить запись с 3-мя полями НАЧАЛО КОНЕЦ ЗНАЧЕНИЕ. Тогда это легко можно получать более простым запросом(даже для акций там скачки не каждую секунду).
Андрей Халецкий
3562 сообщения
#12 лет назад
WebDesignStudio, за такой вариант нужно бить по рукам, как вы из него достанете данные за конкретную секунду? Ну и вы забываете что требования зачастую появляются уже в процессе, так что случится может всякое.

PS. и да, котировки меняются каждую секунду.
Сергей К.
1649 сообщений
#12 лет назад
Цитата ("SmartDesign"):
как вы из него достанете данные за конкретную секунду
я думаю вы тут просто шутите
Цитата ("SmartDesign"):
и да, котировки меняются каждую секунду.
согласен, но они меняются не каждую секунду. Так что тут лучше интервалы.
Андрей Халецкий
3562 сообщения
#12 лет назад
Они _меняются_ каждую секунду (для ликвидных позиций, например евро-доллар), хранением интервала вы добьетесь того что вам прийдется выбирать не по значению (простому, легко индексируемому полю типа таймстемп) а по интервалу (двум полям) что выльется в более дорогой индекс и более тяжелую выборку. Кроме того - это слабо поможет решить задачу которую я обрисовал (про непрерывный рост).
Сергей К.
1649 сообщений
#12 лет назад
Цитата ("SmartDesign"):
про непрерывный рост

мой способ как раз лучше, потому что я получаю максимальный интервал(максимальную разницу между двумя полями). Я думаю что на практике не прямо каждую секунду они меняются, в теории может быть.
Андрей Халецкий
3562 сообщения
#12 лет назад
Черт, сколько раз нужно повторить эту мантру: они _меняются_ каждую секунду.
Ну и я там еще несколько пунктов критики решения с интервалами давал, их тоже стоит прочитать.
Сергей К.
1649 сообщений
#12 лет назад
Цитата ("SmartDesign"):
Черт, сколько раз нужно повторить эту мантру: они _меняются_ каждую секунду.
Ну и я там еще несколько пунктов критики решения с интервалами давал, их тоже стоит прочитать.

ну и что? Это проблема? Хранить 2 числовых поля или 1, разница не такая большая, зато обработка намного проще и быстрее будет. А если учитывать что в практике они могут не меняться по несколько секунд или даже минут, даже есть выигрыш с использованием моего способа.
Андрей Халецкий
3562 сообщения
#12 лет назад
Разница не просто большая.
Нужно хранить в два раза больше данных, в два раза больше условий для проверки при выборке.

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

И последний раз: это требование появилось вот сейчас, когда у вас накоплена база за два года, что делать будем?
Сергей К.
1649 сообщений
#12 лет назад
Цитата ("SmartDesign"):
И последний раз: это требование появилось вот сейчас, когда у вас накоплена база за два года, что делать будем

ну если это так то да, мое решение не подойдет. А если проектировать с нуля, я бы не делал так.
Андрей Халецкий
3562 сообщения
#12 лет назад
Цитата ("WebDesignStudio"):
Цитата ("SmartDesign"):
И последний раз: это требование появилось вот сейчас, когда у вас накоплена база за два года, что делать будем

ну если это так то да, мое решение не подойдет. А если проектировать с нуля, я бы не делал так.
Спроектировали, а потом понадобилось посмотреть курсы каждую пятницу четного числа на 12 дня, и все, амба.
Вячеслав Г.
105 сообщений
#12 лет назад
Цитата ("SmartDesign"):
Я четвертый раз пишу что если данных много - то экономия по скорости будет существенная, если данных не много - то лучше делать в скрипте т.к. это наглядное/простое в поддержке/более гибкое решение

Для наглядности, возможно. Для гибкости/поддержки - неужели вносить изменения в скрипт гибче и проще, чем в запрос? Тем более, что сам запрос, как правило, лежит в коде скрипта. Хотя... это действительно спорно.
Я же говорил о том, что со своими данными СУБД будет работать заведомо быстрее, чем внешнее приложение, коим и является любой скрипт.
Вячеслав Г.
105 сообщений
#12 лет назад
Цитата ("WebDesignStudio"):

все зависит от ситуации. Я считаю что в этой конкретной ситуации лучше на стороне скрипта делать.
Вы мне так и не дали пример.

От ситуации не зависит. Пример - любая выборка MySQL, да хотя-бы эта:
SELECT COUNT(milan) FROM table - будет работать быстрее, чем если подсчитывать строки в скрипте.
Дима Г.
87 сообщений
#12 лет назад
Цитата ("WebDesignStudio"):
Цитата (uniq-ip):
WebDesignStudio, в любом случае перебор таблицы в СУБД будет быстрее, чем при помощи скрипта. А эксперимент проведите, чтобы в этом не только качественно, но и количественно убедиться

все зависит от ситуации. Я считаю что в этой конкретной ситуации лучше на стороне скрипта делать.

Вы мне так и не дали пример.


А какой пример дать? Из моего первого поста понятно, что речь идет о бирже. Любая биржа это пример.
А исходники и базы стоят *******$, тебе нахаляву намыло сбросить архифчиг?
Зачем тебе большая база? В запросах обработки статистики индексов, событий, изменений во времени относительно x y z w ...., анализ данных других бирж + еще много гавна и поверь там базы с таблицами с какимито 50.000 записей хватит чтобы посадить php на жопу. Если и делать обработку данных на стороне языка тот там будет C но не как не PHP.

PHP дальше обработки вывода практически линейных данных с базы для интернет магазина не уходит. А когда на стороне сервера идут SQL запросы в 20-50 строк (это не много) перевести на PHP то это будет просто #####. - примеры и проч. хрень просить не нужно, кто работал с такими нагрузками тот знает, кто не работал тому #### что докажеш.

PS без обид
Дима Г.
87 сообщений
#12 лет назад
Я не говорю, что PHP - это гавно. Я говорю, что PHP подходит для отображения инфы + вызова функций готовых библиотек (написанных на более шустрых языках). PHP - это конце концов препроцессор текста и не более того...

PHP мой любимый инструмент, но это не значит, что его нужно сувать в любую дырку. Отображение инфы я делаю на PHP, с базой работая на SQL, сист. скрипты пишу на BASH, а библиотеки на C.
Андрей Халецкий
3562 сообщения
#12 лет назад
Gritskif, О, сколько пафоса!

При том что запрос решающий задачу то в общем-то никаких сверх способностей и знаний не требует.

Выглядит довольно смешно.
Дима Г.
87 сообщений
#12 лет назад
Цитата ("SmartDesign"):
При том что запрос решающий задачу то в общем-то никаких сверх способностей и знаний не требует.


Чево? первую половину предложения не понял. я гдето говорил, что делаю, что-то сверхестественное - обычный анализ бирж. Но запросы довольно еб.... и большие, и если sql заменить на php то это финиш.
Что то не так?
Андрей Халецкий
3562 сообщения
#12 лет назад
Ну что вы. Так размахиваете исходниками которые стоят ****** долларов, пишите на PHP|SQL|C|BASH тыкаете носом что с хайлоадом человек не работал и разговарваить с ним не стоит и т.д.

При этом доказываете кому-то что SQL нельзя заменять на PHP, об этом тут вообще речи не было.