Добрый день! Вот такой запрос: PHP: $gruppa = "grupp_$no"; $xx = "v_$step"; $yy = "a_$step"; mysqli_query($db, "UPDATE $gruppa SET $xx = '$question', $yy = '$ball' WHERE `invite` = '$invite'"); Вроде бы, работает нормально. Но мне не нравится вот что: 1. Имена полей заключаются в одиночные обратные кавычки. Обычно я так и делаю, но как здесь это сделать? 2. Формировать имена полей отдельно - это как-то кустарно. А как это сделать в теле запроса?
Или в переменные включай, или в основную строку запроса (вокруг переменных). --- Добавлено --- Еще можно так: PHP: "UPDATE {$table('table')} SET {$field('field')}=..." И в функциях (они в переменных) можно оборачивать в нужные кавычки. Но это больше нужно для разных диалектов SQL (если используешь только мускул и не собираешься с него слезать, то не нужно). Также функция может быть одна. Я привел две, т.к. в наших поделках table() часто еще и само имя модифицирует, например добавляет префикс, а вот кавычки она может и не добавлять, т.е. может быть и так: PHP: "UPDATE `{$table('table')}`..." --- Добавлено --- Ну или юзай какой-нить QueryBuilder --- Добавлено --- P.S. Если для обычных сайтов тебе часто приходится брать имена полей из переменных, ты скорее всего делаешь что-то не так. Имен таблиц это тоже может касаться, но с ними ситуация все же немного другая.
А что там другого? В моем примере и имя таблицы составлено с использованием переменной РНР. Тоже работает.
Имена таблиц могут браться из переменных, но нефиг создавать 100500 таблиц grupp_1-grupp_100500 Пример: таблица одна, номер (идентификатор) группы в отдельном поле – внешнем ключе.
Две – уже много. Если сущности реально разнотипные и их не надо смешивать в одном списке и т.п., назови нормально таблицы, без этих циферок. --- Добавлено --- Цифру 6 можешь оставить. Будет группа шестерок Или пациентов палаты №6 Но только если они у тебя везде на отдельном учете и нигде не пересекаются с остальными
а что в циферках плохого? PHP: $gruppa="grupp_$no"; mysqli_query($db, "UPDATE $gruppa SET $xx = '$question', $yy = '$ball' WHERE `invite` = '$invite'"); $no меняется от 1 до 6. И все обрабатывается одним этим запросом. Если же дать "нормальные" названия таблицам, то таких запросов потребуется шесть. А какой в этом смысл?
А если нормально планировать задачу, то не понадобится шесть таблиц для одного и того же. Главное свойство программных "костылей" — они потребуют новых "костылей" чтобы минимизировать ущерб. И еще и еще...
В моем случае проще всего было бы все разместить в одной таблице. Но в ней было бы 782 столбца. Мне показалось это неудобным. Тем более, что операции идут только с группами из 7 столбцов. Поэтому я разделил таблицу на 6 частей, а имена полей сделал такими, чтобы к ним обращаться через переменные РНР. Иначе все пришлось бы писать вручную индивидуально для каждой операции. Что не только трудоемко, но и наверняка где-нибудь напутаешь.
ну вот: костыль тебует следующего костыля, а он ещё... 782 столбца решается через связанные таблицы. НЕ ОДИНАКОВЫМИ таблицами, а имеющими осмысленное содержание, имена и связи. а если у тебя после "разрезания" таки получаются одинаковые поля, то очень вероятно, что нужна таки одна таблица, но с полем для группировки. не всегда плохо "писать вручную", кстати, когда то что ты пишешь читается нормально и помогает поддерживать дела в порядке. когда у сущностей есть имена, ты можешь с помощью IDE находить где что используется. даже переименовывать автоматически все случаи использования имени можно. а когда у тебя table_1, table_2... и ты их перебираешь в цикле, то найти где чего можно только приняв дозу LSD ))) --- Добавлено --- P.S. я тебя не уговариваю. тебе выбирать каким путем идти: общепринятым или путём боли. просто я вижу некие маркеры говнокода и тригерюсь на них. в частности на смесь инглиша и руглиша. или на "Формировать имена полей отдельно - это как-то кустарно". ну-ну. оптимизируешь значит количество переменных. окей. потом попробуй ретроспективно оценить чего стоила эта оптимизация в человекочасах. удачи!
Ну, по идее в основе должна быть нормализованная структура, а сверху уже можно наваливать различный кеш, в том числе и в «кеш-полях» таблиц БД. --- Добавлено --- У нас даже нек. таблицы целиком кешируются. Речь о явном кешировании, т.е. копировании или построении при старте, а не временных таблицах и прочей лабуде, поддерживаемой СУБД из коробки.