Let's PHPコミュの連想配列をシリアライズ

連想配列を、シリアライズしてテキストにしてSQLのテーブルに放り込むのは便利な手法です。私は、昔から、base64で、URLエンコードしてぶちこんでいたりしました。最近では、serialize 関数があるので使うのが便利です。
最近このシリアライズの手法がはやってきているようです。
実際に使っている人はいるのでしょうか？はてなできいています。
ご存知あるかたいらっしゃいましたら、ぜひ回答お願いします。
http://q.hatena.ne.jp/1144131231

コメント(16)

最初
全て
最新の40件

[3] mixiユーザー 04月05日 14:07

CVSのログを見れば正確に出てくると思いますけどserializeもbase64_encodeも5年位前からやってます
一番の親URLの言うこともわかりますが，serialize()はあくまでPHPが受け取るから便利なだけでそれ以上もそれ以下もないんですよね．

#某所にはCだかC++のライブラリがあるけど

[4] mixiユーザー 04月05日 14:55

yahooでは使われてるみたいですね。
XMLでなくserailizeした結果のAPI

http://api.search.yahoo.com/ImageSearchService/V1/imageSearch?appid=YahooDemo&query=Madonna&results=1&output=php

[6] mixiユーザー 04月06日 00:43

ＤＢ設計が事前にできない場合を想定しているのです。
データモデルはこんな感じですね。
面白いと思う人は皆無みたいですね。
http://xoops.sourceforge.jp/wiki/free/index.php?%C7%F2%C0%F0%B8%E5%B7%D1%A5%E2%A5%B8%A5%E5%A1%BC%A5%EB%A4%CB%A4%C4%A4%A4%A4%C6

[8] mixiユーザー 04月06日 01:33

6: tadashi さん>>

面白いというか前述の通り昔からやってたんで普通なんですよ

[9] mixiユーザー 04月06日 01:38

>面白いというか前述の通り昔からやってたんで普通なんですよ
実装でバリバリつかっているのはあんまりないんじゃないでしょうか？
検索不要なら、テーブルは１種類だけでオッケーになります。
（さすがそういったことはないですけど）

[10] mixiユーザー 04月06日 01:46

> 実装でバリバリつかっているのはあんまりないんじゃないでしょうか？

ってのは実装数を調べたわけじゃないのでわかりません．
しいていうとストレージへの格納方法としては実際問題NAME,VALUEなテーブルとかCSVより飛びぬけて便利かというとそんなに便利じゃないんです．

> 検索不要なら、テーブルは１種類だけでオッケーになります。
> （さすがそういったことはないですけど）

自明な部分ですよね．

で，wiki何年も前から何度も言ってて恐縮ですけどカテゴライズにご協力ください(苦笑

[11] mixiユーザー 04月06日 02:55

複数のWEBサーバーがあったりしてセッション情報をレプリケーション
しないといけないような場合、DBにシリアライズしたデータをセッションとして保存したことはあります。

検索が必要じゃなくて、PHPからしか使わないんだったら便利ですね。

[12] mixiユーザー 04月06日 08:55

＞しいていうとストレージへの格納方法としては実際問題NAME,VALUE
＞なテーブルとかCSVより飛びぬけて便利かというとそんなに便利じゃないんです．
うーん、そこがよくわからないのですが、NAME,VALUEは私のいうタテ展開だと思いますが、違いは、変数を意識するかしないかだと思います。何がくるかわからないけど、ぶちこんでおけというなら、シリアライズが楽だと思います。
もちろん、タテ展開でも、すべて展開してぶちこむなら同じですが、
それから、連番に工夫があります。すべての種類のデータに連番が振るので、連番さえ指定すればデータをとってこれます。データ取得のメカニズムが簡単になります。プロフィール情報も、ショッピング履歴もすべて同一の連番を振ります。
どんな種類のデータがあるかも事前にわかっていないのに対応するためです。
また、
白扇のスレッドを見るとわかるように、システムの仕様に関しては、いろんなリクエストがあります。それらに柔軟に対応するのはどうしたらいいのかなというのでこういったデータモデル考えているわけです。

http://xoopscube.jp/modules/xhnewbb/viewtopic.php?viewmode=thread&topic_id=2577&forum=2

それから、wiki のカテゴリはどこにいれるといいのでしょうか？
（カテゴリマネジメントは、難しいです。）

[13] mixiユーザー 04月06日 09:26

こんにちは。

この手の「項目数や種類が動的に変わるデータ」を保持する際には、昔から似たような方法使われてましたよね。

主にCSV形式で一つの項目にまとめてぶち込む方法だったと思います。最近だとXML形式で保存、なんかも行われるのでしょうか。

そういう意味で、PHPシリアライズの事例といっても特に目新しいものではない為、取り立てて記事にしてある例も少ないのかもしれません。

項目を１つにしてそこへ全データつっこむやり方は、検索や情報取得に制限が出てくるので、一長一短だと思います。流行り廃りではなく使い方の問題かと。でもどちらかというとRDBMSを使う利点を殺す方向の使い方なので、使用には注意が必要だと思います。

また、PHPシリアライズしたものを突っ込む方法の欠点としては、PHPに依存してしまうという点だと思います（言わずもがなですが）。

一般的にプログラム言語は変わっていっても、データは引き継がれて残る事が多いので、特定の言語に依存したデータ構造にしてしまうと、後々面倒があるかもしれませんね。それどころか、PHPシリアライズの仕様が途中で変わる恐れすらあります。（PHPではありませんが、.NET FrameworkのSerializationの仕様が途中で変わって、それをファイル保存にそのまま使っていたプロジェクトが火を噴いたことがありました）

amazon等の例は「データを取り出すインタフェース」としてPHPシリアライズを使っているだけで、内部データそのものがPHPシリアライズされているわけではないという点が、このトピの主旨とは異なる点だと思います。

既に出ている意見とほとんど被ってますが、以上です。

ではでは。

[14] mixiユーザー 04月06日 14:11

> それから、連番に工夫があります。すべての種類のデータに連番が振るので、連番さえ指定すればデータをとってこれます。

ID,NAME,VALUE

なテーブルにするのはどうでしょうか? IDが縦でNAMEが横です．
昔設計したときは

ID,TYPE,NAME,VALUE,OPTION(範囲だったりデフォルトだったり)

みたいなのやりましたけど．
CVSだとそのまま行数が縦でカラムが横ですね．

> 白扇のスレッドを見るとわかるように、システムの仕様に関しては、いろんなリクエストがあります。それらに柔軟に対応するのはどうしたらいいのかなというのでこういったデータモデル考えているわけです。

読みましたけど既にPHPのシリアライズだけでは破綻してませんか?(苦笑

[15] mixiユーザー 04月06日 17:33

この辺の下はいかがですか?

http://xoops.sourceforge.jp/wiki/free/?TECH
http://xoops.sourceforge.jp/wiki/xoops2/?TECH
http://xoops.sourceforge.jp/wiki/xoops2/?DEV

#DEVが言語ファイルだけって説明は笑えるな．開発はそれしかないのかよ(苦笑

といいつつXOOPS wikiは殆どメンテナンスフリーやっちゃってるんで強制はしませんよ．

[16] mixiユーザー 04月07日 09:04

＞ID,TYPE,NAME,VALUE,OPTION(範囲だったりデフォルトだったり)
もち、この方式です。wiki に書いてあります。
実際は、オプションは下記にしてあります。
lang 言語
charset 文字セット
を考えています。
これ以外のオプションは、追い出してあります。

シリアライズ＋たて展開　で、シリアライズが主、タテ展開が従という構造です。理論的にはタテ展開のみでオッケーですが、

＞読みましたけど既にPHPのシリアライズだけでは破綻してませんか?(苦笑
もちろんです。別途考えています。
主データ（シリアライズ、タテ展開）にアノテーション（注釈）という構造ですね。主データは、どのようにアノテーションされているか知らない（主データの中にそのデータがない）けど、アノテーションを特定できると問い合わせ可能になるように考えています。
アノテーションは、ゲノムデータベースで使われる言葉です。

アノテーションはいろいろありますけど、
例えば次のようなものを考えています。
文脈、データa、タイプ,データb
owner 45 profile 501
データa は、profile というタイプのデータb の owner である。

関係を表現するわけです。タイプの項目が必要なのは、
45 は、profile のデータの owner になっているかと検索を
かけるからです。ないという情報をこのテーブルが保持するためには、必要になります。ない　情報を返すのは別にテーブルつくってもいいのですが、一緒にしています。ここらへんは非常に微妙なんで、つくっては壊しというところです。

時間に関しては次のようになります。

設定時タイプ、連番、時刻
入庫 55 4月7日
誕生日 307 5月5日
読み方は、
データ55 は、4月7日に入庫した。
データ307の誕生日は、5月5日
といったところです。データに関してはタイプが設定されていますが、連番（ID)だけで作業はできるようなんで省いてあります。

在庫管理用のデータと、誕生日のデータも同じテーブルにぶち込みます。

ログインすると、残り4件のコメントが見れるよ