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

[juggy]

КТО УМНЕЕ ЗАМОЛЧИТ ПЕРВЫМ!!!!

[advocat]

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

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

[advocat]

Оригинал написал(а) juggy
КТО УМНЕЕ ЗАМОЛЧИТ ПЕРВЫМ!!!!

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

[juggy]

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

[Crazy]

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

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

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

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

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

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

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

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

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

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

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

[Crazy]

Оригинал написал(а) advocat

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

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

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

[juggy]

ля-ля-ля.........

[nagash]

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

[Crazy]

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

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

Глава 8, стр. 211, первый абзац:

Как уже отмечалось ранее, язык SQL весьма далек от полноценной реализации реляционной модели.

(также см. вариант этой фразы на стр.70)

Та же глава, стр. 214, пятый абзца:

в таблицах SQL, в отличие от настоящих отношений, допустимы идентичные строки, поэтому им не требуется иметь каких-либо потенциальных ключей.

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

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

Название SQL вначале было аббревиатурой, образованной от Structured Query Language (язык структурированных запросов), и его было принято произносить "сиквел". Сейчас, когда язык стал стандартом, SQL -- уже не аббревиатура, а название, которое произносится как "эс-кью-эль".

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

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

[MoyaReklama.Ru]

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