-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
SCM
Guest
Фанат, так я и говорю, что у меня работает только когда один запрос в mysql_query.
А в примере alpine там несколько запросов - и вот несколько запросов в одном mysql_query я не могу заставить работать.
Да, я никогда не пользовал сразу несколько запросов в одном mysql_query.
Последовательно несколько mysql_query - это, конечно, было.
А в примере alpine там несколько запросов - и вот несколько запросов в одном mysql_query я не могу заставить работать.
Да, я никогда не пользовал сразу несколько запросов в одном mysql_query.
Последовательно несколько mysql_query - это, конечно, было.
а зачем?
я тебя не спрашивал про несколько запросов в одной функции.
я тебя спрашщивал про несколько запросов в скрипте.
и я не понимаю, почему раьше ты это делал, а сейчас вдруг резко разучился.
а- -главное - непонимаю твоё стремление хапихать всё в одну функцию
-~{}~ 29.08.05 22:53:
хотя я всё равно считаю, что с временной таблицей - лажа
SCM
Guest
Погоди.
Если я выполню подряд несколько mysql_query это всё равно как если бы я выполнил один mysql_query, но с несколькими запросами внутри?
Абсолютно одинаково?
Если я выполню подряд несколько mysql_query это всё равно как если бы я выполнил один mysql_query, но с несколькими запросами внутри?
Абсолютно одинаково?
SCM
Guest
Я не знаю - там локи происходят, может что-то где-то может "нагнуться" не во время, если разделять запросы.
SCM
Guest
Фанат, "нагнуться" в данном контексте - это когда что-то пойдёт не так как если бы выполнялось в одном вызове.
Ты у меня спрашиваешь как будто я в этом виноват - я же чётко сказал, что я в этом не разбираюсь, потому мне помощь и нужна.
Возвращаясь к "хотя я всё равно считаю, что с временной таблицей - лажа" - можешь реально помочь?
Мне уже и тут помогали, я все варианты перепробовал, но пока не получается как нужно. Остался один непробованный вариант с временной таблицей.
Ты у меня спрашиваешь как будто я в этом виноват - я же чётко сказал, что я в этом не разбираюсь, потому мне помощь и нужна.
Возвращаясь к "хотя я всё равно считаю, что с временной таблицей - лажа" - можешь реально помочь?
Мне уже и тут помогали, я все варианты перепробовал, но пока не получается как нужно. Остался один непробованный вариант с временной таблицей.
не вижу там никакой помощи.
да и "вариантов" - всего один.
ты вообще делал, что я тебе сказал?
или вообще не обратил внимание на мои слова, а сразу побежал отвечать альпину, поскольку для этого не требуется никаких трудозатрат?
я не уверен, что получится, но почему хотя бы не попробовать?
да и "вариантов" - всего один.
ты вообще делал, что я тебе сказал?
или вообще не обратил внимание на мои слова, а сразу побежал отвечать альпину, поскольку для этого не требуется никаких трудозатрат?
я не уверен, что получится, но почему хотя бы не попробовать?
SCM
Guest
Мне в сумме дали три подсказки с кодом, я всё это перепробовал (кроме временной таблицы), плюс сам разбирался как мог - моя задача всё ещё не решена.
Ты же ничем конкретным пока ещё не помог, только туманным для меня намёком.
Вот я и прошу - если реально можешь помочь запросом, помоги пожалуйста.
Ты же ничем конкретным пока ещё не помог, только туманным для меня намёком.
Вот я и прошу - если реально можешь помочь запросом, помоги пожалуйста.
SCM
Guest
У меня нет валют.
Есть таблица продуктов и есть таблица истории добавлений продуктов.
Есть таблица продуктов и есть таблица истории добавлений продуктов.
SCM
Guest
нет, так я не хочу.
потому как планируется добавить в историю продуктов ещё полей.
похоже вариант alpine с временной талицей как раз то, что нужно.
всем спасибо за помощь!
потому как планируется добавить в историю продуктов ещё полей.
похоже вариант alpine с временной талицей как раз то, что нужно.
всем спасибо за помощь!
SCM
Guest
не просто добавить, но:
1. добавить полей.
2. апдэйтить их значения.
3. при добавлении новых полей потребуется код апдэйтить не только на показ, но и на добавление.
в результате дублирование и лишние проблемы с поддержкой кода в будущем.
кстати - мои две таблицы в идеале вообще можно свести в одну.
вот только остаётся та же проблема с написанием SQL запроса для всё тех же целей.
1. добавить полей.
2. апдэйтить их значения.
3. при добавлении новых полей потребуется код апдэйтить не только на показ, но и на добавление.
в результате дублирование и лишние проблемы с поддержкой кода в будущем.
кстати - мои две таблицы в идеале вообще можно свести в одну.
вот только остаётся та же проблема с написанием SQL запроса для всё тех же целей.
добавить можно только два поля - дата добавления и айди последней записи в хистори.
если описанный тобой запрос требуется часто, то это будет самым оптимальным вариантом.
прямо такая тяжёлая операция - вместо одного запроса сделать два =)
ты уж ври-ври - да не завирайся =)
Ну опять то же самое.
Ты так пишешь, как будто не надо править код запроса insert. Типа, надо только показать, а добавятся данные в базу сами. Тебе самому не смешно?
И вообще - что это за аргумент - "поля будут добавляться"? Если будут - то добавишь, код поправишь. В конце концов, это РАЗОВАЯ операция.
SCM
Guest
Фанат, ты, пожалуйста, веди себя прилично.
Чтобы обвинять человека во вранье нужно иметь веские на то причины.
Ничего из мною сказанного не позволяет тебе такое говорить, а мне выслушивать.
Я ещё раз повторю: я пишу не жёсткую систему, поля могут и будут добавляться в достаточно большом обьёме.
Апдэйтиться они будут также не из одного места.
Документации на систему будет ноль (как обычно), поэтому перечня где все эти места будут перечисляться и затем учитываться тем, кто вносит изменения - такого не будет.
А если не доккументировать, тогда очень может получиться что где-то что-то забудут при очередном апдэйте базы\скриптов добавить.
+ отдельного тестировщика на проект нет - поэтому риски очень велики чтобы ими вот так бросаться.
Когда реально данные динамические запросы действительно будут вызывать проблемы, тогда ничего не будет стоить ввести необходимые статические поля и апдэйтить их при необходимости вместо их калькулирования на лету.
Но везде и напропалую применять подход "имей десятирную избыточность информации и сопутствующий геморрой" я не стану ни с чьими уговорами.
Тему уже можно закрывать, моя проблема успешно решена, а вопроса об организации моей базы я не задавал.
Чтобы обвинять человека во вранье нужно иметь веские на то причины.
Ничего из мною сказанного не позволяет тебе такое говорить, а мне выслушивать.
Я ещё раз повторю: я пишу не жёсткую систему, поля могут и будут добавляться в достаточно большом обьёме.
Апдэйтиться они будут также не из одного места.
Документации на систему будет ноль (как обычно), поэтому перечня где все эти места будут перечисляться и затем учитываться тем, кто вносит изменения - такого не будет.
А если не доккументировать, тогда очень может получиться что где-то что-то забудут при очередном апдэйте базы\скриптов добавить.
+ отдельного тестировщика на проект нет - поэтому риски очень велики чтобы ими вот так бросаться.
Когда реально данные динамические запросы действительно будут вызывать проблемы, тогда ничего не будет стоить ввести необходимые статические поля и апдэйтить их при необходимости вместо их калькулирования на лету.
Но везде и напропалую применять подход "имей десятирную избыточность информации и сопутствующий геморрой" я не стану ни с чьими уговорами.
Тему уже можно закрывать, моя проблема успешно решена, а вопроса об организации моей базы я не задавал.