В этом тексте прекрасно все.
И ochen' russkie названия полей с таблицей.
И использование mysql_ (а местами - mysqli_ !!!) %)
И подстановка переменных прямо в запрос, без всяких там плейсхолдеров. Причем одна из них - путь, по которому потом скрипт полезет "за картинкой".
И наворачивание трех запросов там, где должен быть один INSERT ... ON DUPLICATE KEY UPDATE
И особенно - то, что автор уверенно отметил его решением.
Верной дорогой идете, товарищи!
res2001, обычно знание недокументированных деталей реализации скорее вредно, так как их использование вполне может стать причиной проблем после обновления.
Однако то, что HANDLE - это на самом деле PVOID, указано в документации.
И сразу наводит на мысль, что это самое "целое, без подробностей", например, при переходе на x64 удлинится вдвое и может преподнести сюрприз, если вы имели неосторожность с ним работать не только в функциях WinAPI ;)
sddvxd, нет, именно на эти грабли я не наступал.
Я плотно писал на С/С++ лет десять, но это были прикладные программы (не дельфоподобные, конечно, но и не лезущие всерьез в систему). WinAPI мне за это время понадобился только однажды, и изучения в этот раз не потребовалось - обошелся гуглением.
Если вы собираетесь писать низкоуровневые утилиты под Винды - возможно, вам нужны эти знания. Если вы реально считаете это перспективным направлением развития. Я в этом, признаться, сомневаюсь, но это только мое мнение. Особенно сомнительное оттого, что Виндами я в последние годы практически не пользуюсь.
sddvxd, увы, востребованы не столько знания, сколько навыки.
Если в Сях и Крестах мне ассемблер еще как-то помогал, то в Пыхе, например, его применить практически некуда.
Если быть реалистом, стоит все-таки прокачивать именно навыки решения востребованных задач. Если попутно удастся копнуть глубже в тему - это прекрасно. Но становиться высоклассным специалистом в невостребованной области - чревато большими разочарованиям... да и невозможно стать именно высококлассным спецом, если область применения знаний не востребована и не развивается.
Где сейчас спецы по Дельфям, FoxPro, MFC?
sddvxd, да балуйтесь, ради бога. Просто не рассчитывайте, что этот опыт конвертируется во что-либо ценное. Таких утилиток за годы существования Виндов написаны вагоны, новые мало кому нужны. А когда подобные функции требуются в современных проектах - то используется не голый WinAPI, а сто лет как отлаженная высокоуровневая обертка вокруг него на каком-нибудь Шарпе.
sddvxd, дело в том, что в IT практически невозможно нахвататься знаний по учебникам "про запас, пусть будут". То, что не получается применить в работе - не усваивается и только тратит время.
Извините за оффтоп, но вы уверены, что хотите потратить свое время именно на изучение этих дебрей?
Востребованность на "крестовиков" давно ушла в "кроссплатформенный", "высоконагруженный", "распараллеленный" и прочие распознавания образов и нейронные сети. Копание в древних виндовских потрохах - не самая популярная ниша уже сейчас. Уж лучше с POSIX познакомиться поближе, имхо.
Я, собственно, понимаю, что цифирь 0,0009 - это отработал кэш, а не запрос.
Но и 7 секунд переваривать две таблицы по 20к строк в каждой - это же несерьезно!
abroabr, данные строго идентичны, с одного дампа. vlarkanov, ну естественно, под нагрузкой. Но отнюдь не чрезмерной.
Шаред из дорогих, простые запросы его не укладывают. Собственно, на нем же на другой базе Битрикс крутится без особенных тормозов.
Наевшись старшего Битрикса, я бы очень осторожно надеялся на те возможности, которые заявлены из коробки. Бывает, что допилить их до того, что действительно нужно, сложнее, чем написать нужный функционал заново.
Проверить свободное место, зная, сколько его нужно - это, конечно, rocket science.
Понятно, что могут быть нюансы - но хотя бы предупреждение выдать, как делают приличные люди?
Андрей Николаев, я связываю несколько фактов.
Ошибка в базе, к которой установщик не готов.
Техподдержка, которая отвечает отписками.
Первый встречный, который отвечает дружелюбнее, чем официальная поддержка.
Сапиенти сат.
Одиночка Айс, опыт Битрикса показывает, что мешанина из HTML и PHP в материалах - известное зло, и WYSIWYG-редактор на странице это зло только усугубляет. Ну, и сделано это в Битриксе с фирменной кондовостью.
Делать решения по юзабилити, опираясь на опыт Битрикса, пестрящего неудачными решениями - вообще не лучшая идея.
В Ларе, например, дополнительный функционал на странице, доступный только пользователю с определенными правами, делается просто и естественно.
А вы не путайте date (который выдает время суток от таймштампа) и TIME, в котором часов может быть больше, чем в сутках. А если вам добрый пых еще и таймзону пересчитает...
В общем, приведите данные вручную к секундам, умножьте и разделите на части обратно. Плевое же дело.
