Сохранение ассоциативного массива в строке

[Romashov]

Сохранение ассоциативного массива в строке

Заранее неизвестно сколько придётся хранить данных в БД (полей), но известно что количество переменных(элементов массива) будет расширяться по мере апдейта ресурса, расширять таблицу "вширь" ALTER-ом не очень удобно, и в данном случае неэффективно.
Задача: сохранить ассоциативный массив в одном поле Бд.

Перефразировав вопрос, интересует следующее:
Каким самым оптимальным способом можно преобразовать ассоциативный массив в строку, с возможностью обратного преобразования?

Использовать implode и explode, или есть более удачные варианты для этой задачи?


Храниться будут текущие (сеансные) настройки пользователя, т.е. аналог сессии, но с идентификацией пользователя не по SESSID, а по имени (если залогинился), либо по айпи+браузеру. Использовать сессию не хочу из-за увеличения адресной строки.

 

[Сергей123]

>> сохранить ассоциативный массив в одном поле Бд
[m]serialize[/m]

 

[Фанат]

Типичный пример неправильной постановки задачи.
Перефразировав ответ: Тебе не нужно сохранять ассоциативные массивы в сроку.
Все делается средствами самой базы данных.

Наша БД потому и называется РЕЛЯЦИОННОЙ.
Что можно представлять данные не в виде одной таблицы, а в виде СВЯЗАННЫХ таблиц, которые могут реализовать любую потребную структуру.

Ой!
А дальше-то вообще идет каша-малаша!
Вынужден тебя огорчить. Сессиями тебе пользоваться придется. "по имени" идентифицировать пользователя у тебя не получится

-~{}~ 04.01.05 16:38:

Бресь Сергей, вот реально. Честное слово. я тебя очень не люблю. За глупость. За буквальность.
За тупость ответов. которые не поднимают спрашивающего на твой уровнеь, а ты опускаешься со своими ответами на его.

Тьфу на тебя.

 

[Сергей123]

Хотя, возможно, в конкретом случае это может оказаться костылём.

-~{}~ 04.01.05 15:41:

О, и Фанат так думает.

 

[fog]

Какой смысл вообще что-либо хранить в базе в сериализованом виде, если с данными потом работать не получится нормально. Поиски, сортировки, выборки любые.

 

[Фанат]

Вопрос, в этом топике чудовищно неправилен.
МНОГОУРОВНЕВО неправилен.

Отвечать надо в корень проблемы.

 

[Romashov]

Дам небольшие разъяснения.
В данном случае мне не нужно будет контролировать введённые данные, проволить их обзор, хранить историю.
Эти данные будут необходимы только для текущих значений, а не для истории.
Например количество тем на страницы - мне не важно, у кого из пользователей больше всего тем на одной странице, мне, мягко говоря это не интересно, данные всё равно будут периодически подчищаться, мне в данном случае была важна рациональность и экономичность структуры таблицы при большом количестве обращений к ней.
То есть стурктура таблицы, назовём её хост заключалась в хранении id,date,нескольких заголовков (реферер, ip, браузер) + какое-то множество переменных настроек, для каждой из которых заводить поле было бы очень нерационально.

Спасибо за ответ Бресь Сергею, это было именно то, что нужно.

 

[Фанат]

мужык.
не затруднит тебя рассказать, как ты собрался идентифицировать пользователя не по SESSID, а по имени после логина
И чем это принципиально отличается от идентфикации по SESSID?

 

[4m@t!c]

2 Romashov
То, что тебе говорили все, кроме Бресь Сергей - нужно воспринимать, как конструктинвную критику. Ну, не пишутся код, по идеологии, что сгеодня программа осуществляет поиск, а завтра мы планируем, модифицировать этот скрипт и запускать космичесские корабли. Должно быть четкое ТЗ, и как результат четкие возможности. Планируете космические корабли, разарбатывайцте соотвествующий код. Да, масштабируемость должна быть, но без фанатзима. А Бресь Сергей просто выдал вариант, не глядя в корень. Все мы хотим писать граммотный и качественный код, а такой подход, как у Вас, он в конечном итоге загрузит вас самих же. ИМХО, Лучше строить новое, чем модернизировать стараое.

 

[Romashov]

SESSID настроены у хостера сразу на кукисы и на URL - это очень неудобно, так как это каверкает адрес, что не нравится пользователям конечным, точнее лишает адрес запоминаемости и мешает поисковикам. Точнее мешает мне в конечном итоге. Потом, хранение SESSID в адресе накладывает ограничение: браузер закрыт, новая сессия, новые настройки, новый юзер.

В моём случае - для пользователей
1. С кукисами - в них хранятся ID юзера, хэш ("пароль"."пароль"). По этому делу на каждой странице проверяется его вход, если да, то подгружается соответсвтвенный массив пользователя из БД (имя, адрес, ...настройки отображения)
Настройки отображения - это отдельный массив.
Если нет - пользователь гость - просьба зарегиться, войти, или оставаться безымянным без сохранения настроек.
2. Без кукисов - ничего не поделаешь - носите с собой в ссылке хэш своего входа.
Если гость - то вам эта роскошь не положена (обращено к поисковикам)
Если не сложно, укажите, пожалуйста, основные дыры в такой системе. Уверен, что она их содержит, так как разрабатываю всего 2-ой проект, но достаточно крупный. Поэтому мне это важно.
Сорри за вынужденный (запрошенный) оффтоп.

-~{}~ 04.01.05 17:30:

To: 4m@t!c
Я и воспринимаю это как конструктивную критику, пришёл ведь за советом, опыта набираться
Я думал, ведь опций со временем я сделаю ого-ого, посещаемость повысится, то объём Бд станет огромным. Это не мне надо,т.к. хостинг ограничен 150 МБ.
Да и потом - не резервировать ведь заранее кучу столбцов для данных, которыми может быть никто не воспользуются. Удобнее хранить один массив с комплексом данных, нужных конкретному пользователю, но бесполезными в совокупности.

В данном случае ТЗ - спроектировать так, чтобы в будущем было возможно оптимальное расширение количества различных опций.

 

[Screjet]

Опции/Фитчи/Другое выстраивай строчками, а не колонками. Получишь необходимую гибкость.

А вообще очень рекомендую изучить что такое реляционные БД (похоже именно с этим у тебя проблемы).
И еще рекомендую поменьше заниматься писательством, побольше читательством и поиском.

 

[Romashov]

Писательство - скорость набора позволяет
Про реляционные БД знаю.
Но в данном случае - если для каждого подключения опции у конкретного пользователя создавать строку, то объём этой таблицы будет большой, сокрость прироста огромная. Посещаемость ок. 1000 хитов в сутки.
Потом из этой табл. придётся выборки производить по пользователям - ещё лишняя затяжная нагрузка.

 

[Screjet]

Посещаемость ок. 1000 хитов в сутки.

Думать о быстродействии на этапе проектирования = хорошо. Но без опыта = бессмысленно.

Всегда есть два пути: высокая скорость либо высокая гибкость. За тобой выбор, нео

 

[Romashov]

В данном случае, как раз гибкость не нужна (данные не имеют значения, это только инструмент), но значение имеет скорость и простота.

 

[Фанат]

суть в том, что изначальная посылка о том, что сессии не подходят - неверна.
и БД тут вообще не при делах.
совершенно.

-~{}~ 04.01.05 19:05:

Без кукисов - ничего не поделаешь - носите с собой в ссылке хэш своего входа.

Использовать сессию не хочу из-за увеличения адресной строки.

без комментариев

-~{}~ 04.01.05 19:17:

Посещаемость ок. 1000 хитов в сутки.

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

-~{}~ 04.01.05 19:19:

SESSID настроены у хостера сразу на кукисы и на URL - это очень неудобно, так как это каверкает адрес, что не нравится пользователям

никто немешает тем, у кого есть куки, сид просто не показывать

Потом, хранение SESSID в адресе накладывает ограничение: браузер закрыт, новая сессия, новые настройки, новый юзер.

противоречит предыдущему.
Написано же - что И В КУКАХ. т.е. никто в адресе ничего не хранит.
налицо постановка неверной задачи из неверныхисходных данных

 

[Romashov]

Предложеныый механизм не уступает сессиям, однако он более прост в использовании: легко перебрать все отмеченные свойства перебором массива $options с помощью foreach, в котором не будет ничего лишнего (даты, имени юзера, др. данных), которые в моём механизме хранятся отдельно от сериализованного поля опций. В сессиях пришлось бы обнаруживать и игнорировать эти данные, что не радует красотой решения.
+всё равно бы пришлось некоторые данные из сессий сохранять в БД
+время хранения сессий на серваке зависит от хостера, а не от меня
+сессии без БД не позволили бы вести статистику посещаемости
+механизм позволяет без мороки посчитать гостей и вывести зарегенных юзеров "онлайн".
В любом случае, работа в БД необходима, а вот сессий можно избежать.

 

[4m@t!c]

Вот ты как даешь ссылку другим - берешь адресную строку - копируешь и шлешь. У меня отключены куки. Я отдаю свой "вход" в адресной строке и тот, кому я послал урлу тсановится мной... мда.. очень удобно.... то же самое с куками.
Не понял фразу

В любом случае, работа в БД необходима, а вот сессий можно избежать.

А, вообще, туманно все написано и непонятно...))).. Может, мне просто опыта не хватает...))

 

[Фанат]

Объясняю один раз.
Надеюсь, каша в твоей голове прояснится.

Сессии - это механизм идентификации браузера.
В виде бонуса - механизм сохранения СЕАНСОВЫХ переменных.
К сожалению, ты этого не понимаешь, и пытаешься навесить на сессии функции базы данных.

Твоя проблема в том, что ты стремишься сделать все только одним механизмом. или сессиями или бд. Естественно, оба варианта получаются уродливыми, и тебе приходится выбирать из двых зол.
Вместо того, чтобы пользоваться ОБОИМИ механизмами одновременно, каждым - по назначению. Плюс - куками.

Ты смешиваешь постоянную информацию о юзере с сеансовой.
ТЫ смешиваешь. И при этом ставишь это в упрек сессиям.
Сессии не хуже и не лучше БД. Это СОВСЕМ другой механизм.

Сессий, как ты верно заметил, можно избежать. Правда, ты делаешь это не потому, что тебе не нужны сессии, а потому, что ты не понимаешь, что это такое.

 

[Romashov]

Я прекрасно разбираюсь как в сессиях, так и в БД. И не путаю, и не пытаюсь заменить одно другим.
Смысл моих постов - в том, чтобы попытаться разобраться как оптимальнее (нагладнее, проще, свежее, легче, быстрее, правильнее) решить задачу объединения скриптов аутентификации, статистики, поддержки пользователя данными и фичей "кто онлайн".
В данном случае не хватало всего одного шага - сохранить массив в БД. Оптимальным оказался вариант с запиьсю его в строку - вот об этом я и спросил.

Я не смешиваю постоянную инфу о юзере с сеансовой. Где это я говорил?

 

[Фанат]

В сессиях пришлось бы обнаруживать и игнорировать эти данные, что не радует красотой решения