Q&A
「ように」といっても100％Twitterと同じではないですよね。
もっと具体的に要件詰める必要があるのではないでしょうか。
現在提示されている情報だけでは判断できません。
そして、開発の希望やサービスの形態次第ではQAという形では解決難しい内容かもしれません。
タグ機能を実現するための便利なデータベース設計を３つ紹介という記事を拝見し、タグ付けにおけるデータベースの種類を知ったばかりです。
今回Twitterのようにユーザー自身がタグ作成できるものを開発していて、つまりタグの数が膨大になることに耐えられなければなりません。
この場合に適当なデータべースは上記の記事3つ目にあるToxi法でよろしいでしょうか。
正規化が進んでいるとはいえリレーションテーブルが膨大になることにやや不安を覚えます。
無論これら3は一長一短ですが、ユーザー自身がタグ作成できるという場合に適した方法はどちらになりますでしょうか。
ご意見頂けましたら幸いです。
膨大になる事がリスクになる程の利用者数なんですか？
toxiという名前は初めて知ったけど、世の中無駄に名前つけたがるご機嫌な人がるんですね。中間テーブルとか多対多リレーションって言葉使った方が良いですよ。阿呆に釣られて造語使うよりも情報検索し易いですから。
MySQL限定の話ですよね。
MySQL限定になります。
利用者数の返答無しか そしたら本当に膨大なら膨大でも対応出来るような設計に、そうでもないなら好きなようにって感じで。
タグをどう使いたいのでしょうか？それによって答えが大きく変わります。
> タグの数が膨大になる
他の方も質問されていますが、どれぐらいを想定しているんですか？
タグの使い方としては。Twitterのようにコメントにユーザーがー好きにタグ付けでき、それを検索できるという使い方を考えています。そのため数としては多言語も想定し、億単位はいっても耐えられるように作りたいという思いです。
「～のように」という表現をイメージわかしやすくするために使っているのかもしれませんが、
結局そのものとは似て非なるものになるので、あくまで自身が作るものとして「仕様を」「具体的に」書いたほうが良いと思いますよ。
それに、言っては悪いですが、本当にそれだけのユーザー数、データ数を見込めるようなサービスになるんですか？
それならこの場で無償で解決できるような問題でも、個人プロジェクトで考える問題でもありません。
回答1件
0
ベストアンサー
タグの数が膨大になる
億単位はいっても耐えられるように
一人当たり、100件のタグを作ったとして100万人の利用者という事になります。
タグの事だけ気にして良いの？って感じですよ。
Twitterのように
規模の例えでは無いでしょうが、Twitterは日々スケールアップしての現状です。
コスパを考えた方が良いと思います。
以下はTwitterの開発技術系のサイトです。膨大なコスト掛けている事が伺えます。
Reducing search indexing latency to one second
本題に入りますが、MySQLでなら、テーブル構造ではなく、パーティションの検討でしょうね。
MySQL限定になります。
何故限定するのか分かりません。
フレームワークやテンプレートありきという話なら、そこで既に限界です。
想定している規模に対しての要件を満たすためには、DBMSも選択肢の一つです。
タグ検索するならPostgreSQLで決まり！
タグのみのテーブル化が不要なら、結合コストも抑えられますからね。
得意分野を任せて、異なるDBMS間の連携だって良いわけです。
投稿2020/10/10 02:57
編集2020/10/10 05:35総合スコア25327
あなたの回答
tips
プレビュー
