Долгосрочное хранение
 

Ребята, как через ПХП,
при обращении к какой -либо системе (например системе платежей), которая не может пропустить через себя инфу, которая мне нужна (передаваемые из формы данные), а потом нри возврате назад на сайт как-бы "восстановиться" и передать скрипту инфу, которая была в форме при обращении к системе платежа??? :cool: :cool: :cool:

записать в куки переменные...
а лутше даже не в куки а в сессии... чтобы на компе не храить..!

Существует 3 способа:
1. Хранить на компьютере пользователя в кукисах
2. Хранить в сессиях
3. Хранить в БД

На самом деле 3 способ мне кажется лучше 2-х предыдущих. По крайней мере до этой информации легко добраться в случае чего. ;-)

А вообще-то 1 способ считается ламерским, т.к. не только это все можно изменить, но и просто эта информация легко может пропасть.

Если идет речь о долгосрочном хранении, то это однозначно или СУРБД или в крайнем случае файл БД на сервере, так как уже и упоминалось, куки можна стереть, изменить и тд, а срок жизни сессии определяется настройками пхп на сервере ...

СУРБД это что такое? :-) Может СУБД?

Именно СУРБД :D
Система управления реляционными базами данных ... кстати к ним относится и mySQL ;)

JFYI: MySQL не является системой управления реляционными базами данных, ибо не следует буквально заветам доктора Кодда. :)

Реляционной ее называют исключительно в бытовом смысле, так что букву Р выпячивать вовсе не стОит. :)

Crazy ;)

С одной сторонs я согласен, так как СУБД, оно и в Африке СУБД, но есть маленькое но, когда я учил базы было написано черным по белому что MySQL - это именно СУРБД .... так что спорить здесь можно долго, чего делать мы небудем и просто закроем тему ....

Тебе не повезло с учебником. Почитай Дейта. :)

С ним спорить трудно...

Цытирую :

Это ты Дейта цитируешь? Какая страница?

увы, щас ми нескажу откуда, просто с книги ;) автора может весером скажу .... а то писал дома, а сейчас на работе :D

ХОТЯ Я СЧИТАЮ ЧТО ЭТО БЕССМЫСЛЕНЫЙ СПОР, ПОСЕМУ ПОРА ТЕМУ ЗАКРЫВАТЬ ...
У ОДНИХ НАПИСАНО ПО ОДНОМУ, А В ДРУГИМ ПО ДРУГОМУ, И КТО ПРАВ СУДИТЬ НЕ НАМ ....

Судить "кто прав" незачем -- все уже давно определено. :)

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

чем вам не долгосрочное хранение?

Шеф, то, что Дейт и Кодд стоят в области баз данных выше и тебя, и даже :) меня -- вопрос, не требующий обсуждения.

Признаться, я не тестировал совсем уж современные браузеры, но раньше общий объем кук был ограничен и при переполнении самые старые куки просто удалялись. Так что это способ долгосрочного хранения хорош только при постоянном "подновлении".

Как в нормальных условиях этого как правило бывает действительно достаточно. Однако перечитаем первое письмо треда... :)

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

advocat,
ты бы помолчал по поводу ламеров...

Что-то я непонял, это камни в мой огород ? обоснуй, сам то кто ? http://bm.img.com.ua/chat/s45.gif

2ALL GUYS
 

тааак, страсти накаляются и дуэли не избежать...
у меня лежит на полке всем известная книжка Лауры Томсон и Люка Веллинга "Разработка Web-приложений на PHP и MySQL", где ясным языком написано:
В следующем разделе книги будет рассматриваться применение MySQL - системы управления реляционными базами данных. (страница 73)
во вступлении в главу 7 более 5 раз большими буквами употребляется слово СУРБД рядом со словом MySQL а так же рядом с известным именем реляционного гуру: Си Джей Дейт.
еще вопросы? :D :D :D

считаю тему закрытой.

ЗЫ: не пытайтесь возражать, я навел цитату только из одной книги, но просмотрел несколько. так что могу дать список книг, с точным указанием страниц и абзацев, где подтверждается утверждение того, что MySQL - это все таки СУРБД. так что, если куча свободного времени, могу дать повод пойти в библиотеку!

по-моему, вообще не по теме разговор...
не пофигу ли как всё это называется...
главное как это работает...
и для чего!.. :) ;)

...либо ты счел их ламерскими ввиду недостаточности квалификации для понимания. :D Всякое бывает, не правда ли?

Признаться, я не вижу вмысла участвовать в инициированном тобой направлении "кто здесь ламер", ибо также имею весьма конкретное мнение по данному вопросу, однако не испытываю потребности убеждать именно тебя в справедливости моих взглядов. :)

Re: 2ALL GUYS
 

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

Если общественность желает -- завтра могу дать точную цитату с номером страницы. :)

Re: 2ALL GUYS
 

Ламерских книг не просто много. Их большинство. :) Так что можешь не стараться.

Вы же на кусочки орвете друг друга.
РЕБЯТА!!! ДАВАЙТЕ ЖИТЬ ДРУЖНО!!!

Лично я с удовольствием оттягиваюсь. :)

Сходите на Mysql.ru/com и поспрашивайте там !
А тут чего спорить.

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

Если тебе хочется показать какой-ты крутой, то тебе здесь не место !!!

Давайте решать проблемы как в детском саду
 

и вот что получилось ....
http://www.mysql.ru/docs/gruber/ - пять таки реляционные ...
http://www.mysql.ru/docs/pautov/mysqlrus.htm#What - то же заявление, рискну уточнить, что на главной странице сайта надпись : ОДОБРЕНО ЛУЧШИМИ РОССИЙСКИМИ ПРОГРАММИСТАМИ

Re: Давайте решать проблемы как в детском саду
 

Я молчал ... но крейзи хочется похвастаться своим умом и сообразительностью .... хотя все понимают что это не так ...

http://www.mysql.ru/docs/pautov/mysqlrus.htm#What
Да, против этого хрен попрешь, но мое предложение замолчать остается в силе !!!

Там спорить не с кем, а здесь незачем. Ибо, как я уже говорил, пора вспомнить первые несколько писем, которые были написаны до того, как начались бессмысленные умствования по поводу потребности в реляционных СУБД для решения данной проблемы. :) Итак, освежаем память: изначально спрашивалось, как 'возврате назад на сайт как-бы "восстановиться" и передать скрипту инфу, которая была в форме при обращении к системе платежа'.

Разумный ответ дан практически сразу:

СтОит разве что чуть упорядочить этот рецепт. Итак, насколько я понял постановку вопроса, нам нужно некоторую информацию принять, передать на другой сайт, где она будет обработана, а при возврате с того сайта обратно к нам -- снова продолжить работу с этой информацией.

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

У нас есть два механизсма организации сессий: через URL и через куки. Первый механизм отпадает, поскольку мы проходим через чужой сайт и ID сессии, если передавать его в URL, будет потерян.

Остаются куки. Хранить ли в них собственно сами данные, или же передавать ссылку на данные, тем или иным образом хранязиеся на сервера, зависит прежде всего от того, насколько безопасно хранение на стороне клиента и сколь велики эти данные -- априори это оценить невозможно.

Так что если данные имеют малый объем и попытка поделки их пользователем лишена смысла, то стОит хранить их в куках.

Если данные велики или подмена может сказаться на безопасности системы, то мы обязаны хранть их на сервере, передавая в куках только уникальный идентификатор.

Любопытно, что рецепт "хранить в сессии" хоть и является одной из приемлемых реализаций второго рецепта (хранение на стороне сервера с передачей уникального идентификатора) имеет тонкое место: при использовании этого решения НЕОБХОДИМО запретить передачу ID сессии в URL, ибо в противном случае возможны ситуации, когда ID будет передан на чужой сервер (HTTP_REFERER) и таким образом скомпрометирован.

Так что наиболее безопасный вариант таков: вручную -- не используя механизм сессий PHP -- передавать уникальный идентификатор блока данных, которые хранятся на сервере. Хранить данные можно как в файлах, так и в БД: в обоих случаях требуется только доступ по уникальному ключу и не групповых операций. Это, кстати, означает, что при реализации данной схемы РЕЛЯЦИОЛННЫЕ СУБД не имеют икаких преимуществ перед СУБД какого-либо иного рода.

Re: Re: Давайте решать проблемы как в детском саду
 

:D :D :D

Друг мой, а почему бы вместо личных наездов вам таки не почитать специальную серьезную литературу?

http://www.bolero.ru/catalog/book/pa...-2084241.html?

ля-ля-ля.........
:rolleyes:

о!
я ещё не сказал своего везкого слова!
б*я!

Цитаты по просьбам общественности. Без комментариев.

Цитируется по шестому изданию книги "Введение в системы баз данных", К.Дж.Дейт. К.:Диалектика, 1998. (в настоящее время доступно седьмое издание).

Глава 8, стр. 211, первый абзац:
(также см. вариант этой фразы на стр.70)

Та же глава, стр. 214, пятый абзца:
Собственно, анализу SQL в рамках реляционной модели посвящена вся восьмая глава и настоятельно рекомендуется читать ее целиком, ибо приведенные выше цитаты, конечно же, полностью адекватны только в контексте.

И в заключение -- ехидный выпад в сторону одного из упомянутых в дискусси источников (для тех, кто читал его внимательно):

(стр.15 той же книги)

Прощу прощения за возможные опечатки в тексте цитат. :)

бедный crazy!
у тебя наверное времени на себя не хватает.. это ж надо замарачиваться!