Pavel Designer: >>> реализовать данный макет в фотошопе.
>>> чтобы получить подобное
Типа такого надо было, а так - да, яп снимать правильнее, кто ж спорит.
первое что нужно сделать - залить в папку другого шаблона, проверив тем самым не в путях ли дело, если запустится - с темой все ок, дмайте где косяк, если нет - чего то не хватает, смотрите чего.
Чуть больше подробностей не помешает, с такой формулировкой вопрос удалят, или вам просто не ответят. Постарайтесь оформлять вопросы почетче. Описывайте структуру, данные и обстоятельства при которых возникла проблема и вам с удовольствием помогут.
Сергей Мурко: возможно тогда это имело бы смысл. Но в целом плоская таблица с 30 полями НАМНОГО быстрее работает чем перемножение таблицы на саму на себя, да еще и с вайлдкатами. Если полей конечное известное число делают плоскую таблицу, если значения динамические(например в базе хранятся люди, кони, овцы и телевизоры, и вполне завтра могут храниться велосипеды) то тогда кей валуе как то себя оправдывает.
arswarog: в принципе - желание похвальное, все что можно автоматизировать нужно автоматизировать. Но тут пока возможности современного ии увы не позволяют. Проще навести порядок в системе, а вот как - пока мало данных.
Такие таблицы используют только при наличии многочисленных вариантов данных в таблице, там где их 2 делают обычную таблицу с 2 полями, это быстрее, правильнее и экономичнее по всем параметрам.
John Smith: имхо задача такая: присылают сканы, вводить их лень, искать руками еще ленивее, навести порядок 1 раз не так прикольно как показать миру(или шефу) вундервафлю самописную, которая как скатерть самобранка - пыщ-пыщ и все сделает. Имхо. Или не так дело обстоит, автор тут не уточнил что и нафига.
d-stream: ммм, наш верстальщик опасный тип, курит чистый хтмл... Опасность в хтмл конечно есть, но вовсе не при вводе, скорее при выводе, и тут уже надо включать фильтры вывода. А хранить что прислали.
WQP: напишу даже более наглядно - такие поля используются для хранения данных составного характера, по которым производить поиск не нужно, либо этот поиск не будет критичным(например маленькая база и хитрые объекты по структуре). Во всех остальных случаях классика выигрывает по всем параметрам.
WQP: json вообще не очень быстр, и да, технология поддерживает, это типа как вайлдкат поиск - можно, не не нужно если нет ОЧЕНЬ серьезных на то причин.
web-quest3: написал в ответе, Ищи в гугле как реализовывать регистр, и тут на тостере пару дней назад вроде тоже по регистру спрашивали, тут можно поискать.
web-quest3: Создается объект дб, обычно в бутстрапе, как вариант заносится в регистр, оттуда уже можно его брать в объекты(любые), так как объекты передаются по ссылке то экземпляр дб будет один, а ссылка на него будет в объекте.
