Cygapb-007А ведь Вы пока еще не слышали, что с базой одновременно работает до 1000 пользователей, и почти каждый настраивает эту таблицу "под себя"
Я, правда, тоже пока не слышал, но... надеюсь...Примерно так и есть, около 1000 пользователей, только не с "этой базой одновременно", а каждый со своей базой работает (ну или иногда несколько пользователей на отдел).
tanglirсама идея давать пользователю права на alter выглядит безумноВы опять не внимательно читаете. Права на изменения имеют только админы (и это было мною написано). Нажать 2 нопки для создания нового поля может любой админ, даже тот кто не знает что такое "select" (причём кто-то привык это делать в одном клиенте MySQL, а кто-то в другом), а вот, как вы сказали, "запускать самопальные скрипты" никто не будет...
tanglir...FieldNewValueByNumber...
на сервере работать не будет, о чём вам уже несколько раз сказали. Значит, этим должен заниматься клиент, если уж возникла такая насущная необходимость в подобных плясках на костылях.То что в MySQL
пока ещё нету подобной функции, я понял уже после первого ответа. А код я привёл в пример только для того чтобы показать как просто и изящно можно было бы реализовать Log'ирование изменений всего в несколько строк, вместо мыканья и пыканья которое необходимо будет произвести сейчас, прописывая отдельно сравнение каждого поля (и если скажем в базе 300 полей, то и код будет минимум на 300 строк).
Я уже понял что что для вас любые тригеры и продцедуры - это пляска на костылях, и будь у вас воля, вы наверняка запретили бы их, как источник потенциальной опасности. Остаётся лишь вспомнить, что "люди не любят то, чем не умеют пользоваться". Возможно вы лучший в мире планировщик реляционных баз данных, но программирования боитесь...
А по поводу озвученных мною функций (которые я считаю появятся в MySQL в ближайшее время), лишь поправлюсь, что всё же зря сказал о Field
New ValueByNumber и Field
Old ValueByNumber, конечно будет просто FieldValueByNumber и FieldValueByName, а в тригерах будут работать конструкции типа OLD.FieldValueByName(...) и NEW.FieldValueByName(...)
tanglirInterSkyИли по вашему, если данные хранятся в одной таблице - значит им нечего делать в MySQL, там же нет реляционности"Если данные хранятся в одной таблице"... но они-то у вас хранятся по факту в разных таблицах (название у них одно, но структура изменяется по любому поводу).У каждого пользователя своя таблица, и эти таблицы ни как не связаны между собой. Кому-то надо 3 дополнительных поля для хранения цвета автомобиля, а кому-то надо несколько полей чтобы описать тип грунда в который можно сеять семена данного вида рассады.
tanglirInterSkyСупер ответ! Может ещё в текстовом файле хранить?Поскольку вашу БД может насиловать любой желающий, причём каким угодно способом, то можно и в текстовом файле. Хуже всё равно не будет.Насилывать вы можете кого угодно, а администраторы подстраивают базы под нужды своих пользоваетелей. И ваше предложение - "хранить всё в одном поле", это просто бред... Заявления типа - "Эту базу ведь можно изменить!", не являются основанием для того чтобы отказываться от удобства работы с отдельными полями, их сортировкой, группировкой, и другим набором функционала предлагаемым базами данных MySQL.
alex564657498765453тоесть как бы функционал априори есть и по шире пхпшного $$var, можно сделать на подобеПро адресация я всё знаю (больше 20 лет на Delphi пишу). Но я бы хотел отметить что если вы говорите о
$$var , то вы не правильно поняли то чего я хотел. Я не говорю о доступе к любой переменной, а только к переменным окружения! Тоесть если сравнивать с РНР, то это не $$var, а обращение к $_GET['Var1']; вместо $Var1;
А целом, вместо переписывания тригеров я пока остановился на вашем варианте
1.
set @stmp = CONCAT("set @fold = OLD.",@fname,"; set @fnew = NEW.",@fname,";");
