arswarog: в принципе - желание похвальное, все что можно автоматизировать нужно автоматизировать. Но тут пока возможности современного ии увы не позволяют. Проще навести порядок в системе, а вот как - пока мало данных.
Такие таблицы используют только при наличии многочисленных вариантов данных в таблице, там где их 2 делают обычную таблицу с 2 полями, это быстрее, правильнее и экономичнее по всем параметрам.
John Smith: имхо задача такая: присылают сканы, вводить их лень, искать руками еще ленивее, навести порядок 1 раз не так прикольно как показать миру(или шефу) вундервафлю самописную, которая как скатерть самобранка - пыщ-пыщ и все сделает. Имхо. Или не так дело обстоит, автор тут не уточнил что и нафига.
d-stream: ммм, наш верстальщик опасный тип, курит чистый хтмл... Опасность в хтмл конечно есть, но вовсе не при вводе, скорее при выводе, и тут уже надо включать фильтры вывода. А хранить что прислали.
WQP: напишу даже более наглядно - такие поля используются для хранения данных составного характера, по которым производить поиск не нужно, либо этот поиск не будет критичным(например маленькая база и хитрые объекты по структуре). Во всех остальных случаях классика выигрывает по всем параметрам.
WQP: json вообще не очень быстр, и да, технология поддерживает, это типа как вайлдкат поиск - можно, не не нужно если нет ОЧЕНЬ серьезных на то причин.
web-quest3: написал в ответе, Ищи в гугле как реализовывать регистр, и тут на тостере пару дней назад вроде тоже по регистру спрашивали, тут можно поискать.
web-quest3: Создается объект дб, обычно в бутстрапе, как вариант заносится в регистр, оттуда уже можно его брать в объекты(любые), так как объекты передаются по ссылке то экземпляр дб будет один, а ссылка на него будет в объекте.
Гура: скорее не в трафик а ширину пропускного канала, думаю на хостинге с этим особых проблем быть не должно, если хостинг нормальный. А сколько один запрос - делаете курл, смотрите сколько занимает тело ответа.
Vincent1: Практический пример чего??? Вам написали, посмотрите експлэйн запроса, хотя бы будет понятно на каком этапе проблема, есть подозрение что не хватает индексов на name и age.
логически это 2 сущности, данные и настройки, вполне логично, если у вас 60 настроек нет смысла колбасить таблицу с 66 колонками для простой аутентификации. Впрочем все зависит от задач, тут нечеткая логика, можно и в 1 таблице все держать, если туда только возраст и цвет глаз выносится. В вопросе человек свою задачу описал - что у него за ситуация мы не знаем.
Хомон: если данных много и они относятся не только к данным пользователя(например какие-то внутренние настройки) логичнее и правильнее вынести в отдельную таблицу, тут все верно.
darksladen: при уникальности полей - способ сработает, вопрос в том что в идеале - у вас должна быть корзина товаров, то есть человек выбрал цвет / вкус /размер - нажал "в корзину" - сохранилось, еще айфон хочу черный - в корзину, все, хочу оплатить - форма заказа и из корзины все товары перечисляем.
Как вариант - храните все поля в кукисах, это несложный жаваскриптик, оттуда все переменные можно засетить в форму, можно даже одной переменной закодированной в жсон, на стороне сервера распарсить и обработать. Просто и легко реализуется.
lilikon: Вам не кажется что на каком то этапе ""что то пошло не так"? Не проще сразу делать запрос с выборкой по условию - дата больше текущей, это избавит вас от проблем а) вставки какого-то непонятного числа в непонятное поле; б) перевыборки с числом/без числа; в) перезагрузки странички, которая абсолютно не нужна.
