diepo Сообщение 26/01/2010 21:56 Копия темы
mysql + php подскажите как будет быстрее – хранить инфу в разных полях или же тупо создать 1 поле например, и в него записывать всю инфу ну скажем через символ "|"???

т.е. если хранить в полях – при запросе на базу надо будет брать эти поля и юзать..
а если хранить в 1 ... то надо будет взять это одно и поделить символами – т.е. тут уже и на сторону пхп перепадает чуток..
как думаете или знаете может что лучше? подскажите пожалуйста

RiDDi Сообщение 26/01/2010 22:03 Копия темы
Ну смотря какие действия предполагаются с этими полями ) Например искать по такому полю весьма затратно – как по текстовым полям, раздельной индексации нет.. Плюс неоправданное увеличение объема данных если используются одинаковые значения в масссиве... В общем плохо со всех сторон..

А вообще не через какой символ лучше ничего не хранить в таблицах mysql. Или разные поля если количество переменных постоянно, или в отдельной таблице и через таблицу связей.

С точки зрения скорости самая быстрая система – где продуманы связи. Ибо это дает возможность грамотно подключить кеширование где надо, распределить индексирование и все будет просто летать.

csky Сообщение 26/01/2010 22:32 Копия темы
Если в одном поле, то зачем вам база данных? Храните в файлах.

reshik Сообщение 26/01/2010 22:43 Копия темы
почитай про теорию разработки баз данных. В частности – про 3 нормальную форму

ElisDN Сообщение 26/01/2010 23:09 Копия темы
Ну лично я использую "|" для значений только когда на 100% уверен, что не буду производить выборку:
-- с фильтром по любому этому значению (допускаю только LIKE в глобальном поиске по всему сайту, если это перечисление однородных значений)
-- с сортировкой или группировкой по этим значениям
-- с одновременным вхождением двух и более этих значений (с использованием OR или AND)
-- с арифметическими операциями над этими значениями
И вообще если дальнейших проблем с этим не возникнет.
У меня этот символ чаще заменять перенос строки в заголовке новости, чтоб не заставлять никого в админке <br /> писать. Ещё использую для хранения почти неограниченного числа полей, как, например, инфа о пользователе, которая никого не колышет и по которой конкретно искать никто не будет (как заданные админом дополнительные поля описания товара (userfields) в модуле магазина для DLE) по типу `info`='|::|address|:|г.Москва|::|mob_tel|:|+7920XXXXXXX|::|label|:|...'. При считывании функцией-парсером преобразовываю в массив ('address' => 'г. Москва'; 'mobtel' => '+7920XXXXXXX'; 'label'' => '...'). Сам список полей с типами ('address' => 'text', 'telmob' => 'text' ,'label' => 'textarea') хранится в отдельной таблице, правится из админки и используется для построения формы редактирования профиля.
Но если это просто перечисление одних и тех же значений, то лучше использовать типы полей ENUM и SET, или выделить их в отдельное отношение и организовать связь "многие ко многим".
Вывод: такое слияние можно использовать крайне редко и для не очень важной, с точки зрения функционала, информации.

sidoroff Сообщение 26/01/2010 23:26 Копия темы
См. правила Кодда.
"...правило 1: Явное представление данных (The Information Rule):
Информация должна быть представлена в виде данных, хранящихся в ячейках. Данные, хранящиеся в ячейках, должны быть атомарны. ..."

barmaley-exe Сообщение 27/01/2010 04:04 Копия темы
> Сам список полей с типами ('address' => 'text', 'telmob' => 'text' ,'label' => 'textarea') хранится в отдельной таблице, правится из админки и используется для построения формы редактирования профиля.
А конфиг как реализуете? Создавать целую таблицу под один ряд, имхо, не очень хорошо.

romalkavian Сообщение 27/01/2010 05:47 Копия темы
ржака

romalkavian Сообщение 27/01/2010 05:50 Копия темы
Когда-то при мне засыпали этим вопросом соискателя на должность вакансию прогера PHP. Для конфига делают таблицу с полями "название" и "значение", грубо говоря. И очень просто добавляют новую настройку как новый ряд в таблице.

clockworkbird Сообщение 27/01/2010 07:31 Копия темы
8-)

clockworkbird Сообщение 27/01/2010 07:32 Копия темы
Быстрее всего в уме запоминать )

barmaley-exe Сообщение 27/01/2010 09:45 Копия темы
Гм, вариант. Но, имхо, все равно не очень рациональное решение. Ведь после сдачи проекта новые настройки не будут добавляться, а значит таблица будет статична.

romalkavian Сообщение 27/01/2010 12:08 Копия темы
какого проекта? Вы под каждый проект пишете движок полностью с нуля?)) попробуйте создать свою "рыбу" или использовать готовый фреймворк, офигеете, насколько производительность повысится))

Если делать один движок за всю жизнь – да, лучше по-другому хранить настройки, лишний запрос к базе) а если вы клепаете по три сайта в месяц (совершенно разных) – лучше так, как я предложил – однозначно)

romalkavian Сообщение 27/01/2010 12:12 Копия темы
да уж о_О

насчет <br /> – о функции nl2br слыхали, не? Попробуйте использовать, очень полезно, и в админке не надо тоже ставить <br /> ))

А насчет '|::|address|:|г.Москва|::|....' вы меня под стол укатили. Открываю вам огромную вселенную в пхп – очень круто сериализовывать данные и хранить их в текстовом виде (serialize)

ElisDN Сообщение 27/01/2010 14:07 Копия темы
> насчет <br /> – о функции nl2br слыхали, не?

Слыхали. Попробуйте её использовать в поле типа text, а не textarea.
А на textarea у меня редактор TinyMse повешен.

> А насчет '|::|address|:|г.Москва|::|....' вы меня под стол укатили. Открываю вам огромную вселенную в пхп – очень круто сериализовывать данные и хранить их в текстовом виде (serialize)

Скажите это разработчикам коммерческого модуля магазина DLE, у которых я идею подсмотрел

ElisDN Сообщение 27/01/2010 14:12 Копия темы
В смысле под один ряд?

romalkavian Сообщение 27/01/2010 14:29 Копия темы
Хм. Т.е. кто-то мучает пользователей так, что заставляет их вводить многострочный текст в обычный инпут? Я попытаюсь поверить, что это чем-то оправдано, но все же очень удивляюсь. Это как использовать молоток для рубки дерева о_О

Насчет второго – главное, мозг, а не разработчики чего-либо (особенно DLEвские индусы, нашли тоже мне гуру, еще бы джумлу вспомнили).
"При считывании функцией-парсером преобразовываю в массив" – это показатель ума, да. Ну ладно, ближе к делу – есть массив) сериализуем его функцией serialize (поверьте, она без ошибок работает, все данные в сессии пхп именно в таком виде хранит, если вы не знали). Сохраняем в базу. При надобности делаем unserialize и все :) без всяких модных и крутейших функций-парсеров

ElisDN Сообщение 27/01/2010 14:43 Копия темы
Нафиг? А если мне инициалы с фамилией в названии новости захочется на вторую строку перенести, то что, для этого целую текстарею для этого на всякий случай делать? Покажите мне админку, в которой поле для заголовка материала текстареей сделано или WYSIWYG редактором.

ElisDN Сообщение 27/01/2010 14:47 Копия темы
А чем unserialize тогда не функция-парсер?

ElisDN Сообщение 27/01/2010 15:10 Копия темы
Вы бы ещё адрес на "город", "улицу", "дом" и "квартиру" по ячейкам рассщепили просто так и телефон на "код страны", "города" и т.д. если даже это совершенно не нужно. В данном случае это "адрес" и "телефон". Разница лишь в уровне абстракции, что считать за элемент. В том же DLE Shop это необязательные пользовательские данные, одним словом "Дополнительное описание" (типа "собачка любит махать хвостом" и "часто гадит"), которое содержится в одном поле "userfields" и в фильтрах никак не фигурирует.

romalkavian Сообщение 27/01/2010 15:25 Копия темы
ну чувак, никто не делает такой бред) движок и верстка должны быть унифицированными, чтобы любой возможный контент отображался так, как задумано изначально. Отображение – это и есть задача движка (в частности, css этим целям служит).

romalkavian Сообщение 27/01/2010 15:29 Копия темы
т.е. вы не видите никакой разницы между написанной функцией-методом и "родной" функцией языка? Я так понимаю, проектов, где борешься за каждую миллисекунду быстроты, вы еще не разрабатывали :) ну, уверен, это еще впереди и тогда все поймете. И то, почему все надо унифицировать максимально, и почему надо стараться использовать нативные функции.

Одно дело сайт со статическим контентом или у которого посещаемость человек триста в день. Другое дело высоконагруженные порталы с ежеминутно обновляющимся контентом (коих у вас за плечами нет).

ElisDN Сообщение 27/01/2010 17:22 Копия темы
Длинный заголовок поудобней перенести – это преступление?

romalkavian Сообщение 27/01/2010 17:28 Копия темы
ну вот есть мультиблог, куча юзверей пишут свои посты с разными длинами заголовков. И чего, вы им доверите расставление | или будете целыми днями сидеть и сами их расставлять? Все эти вещи делаются обрезанием под нужную длину, автоматической расстановкой переносов после нного количества слов, длиной контейнера, где этот заголовок и т.д. – но уж никак не так, как вы делаете)) повторюсь – это все годится для мелких сайтов, контент которых месяцами один и тот же висит.

ElisDN Сообщение 27/01/2010 17:48 Копия темы
Я не про мультиблог, а про типичный сайт с одним админом говорю. Если вдруг в "... как говорил А.С. Пушкин" фамилия перенесётся, то я тупо вручную перенос перед "А.С." поставлю и всё. Если я сделал дополнительный функционал, то по-вашему хуже стало?

romalkavian Сообщение 27/01/2010 19:34 Копия темы
лан, забей) можт и не хуже, я просто залупаюсь. Просто не люблю я неочевидные вещи и могущие приводить к ошибкам теоретически в некоторых ситуациях..

diepo Сообщение 27/01/2010 19:59 Копия темы
все ребята мир =))

madesst Сообщение 02/02/2010 19:35 Копия темы
А понтов-то сколько =)