問題タブ [schemaless]

多数の多対多および階層構造を構築する一連の変換を通じて一連のテキスト フィールドと数値フィールドを取得するアプリケーションを開発するために使用できるビジュアル データベース アプリケーション開発ツール(GUI ベースまたはスクリプト) を探しています。データ要素間の関係 (複数の主従関係など)

[編集 - 最初の質問以来]

DBA がテーブルと SQL を定義できるようにする多くの製品を見つけました。そして、「デザイナー」はこれらの GUI PHP ジェネレーターを使用して、MySQL テーブル/SQL に対してフォーム ベースの Web ページを作成できます。

• スクリプトケース
• Xlinesoft phprunner
• コードチャージ
• SQLmaestro phpgenerator

これらのソリューションの賛否両論についての洞察をいただければ幸いです。たとえば、コードはどの程度きれいに生成されますか? 「純粋な」スクリプト出力とは対照的に、実行時のセットアップがより複雑なものがあることに気付きました。

どうもありがとう

.net アプリケーションからのスキーマレス アクセスを可能にする SQLite データベースのラッパーを作成しようとしています。アイデアは、各エンティティを単なるコレクションまたは属性値のペアとして持つことです。

パフォーマンスよりも開発者にとってのシンプルさと使いやすさが優先されますが、メモリ使用量とディスクの読み取り時間を完全に無視したくはありません。

私のラッパーのアーキテクチャは、少なくともすべての主キーが最初のクエリで読み込まれる (そしてキャッシュされる) ことを意味しますが、他の属性は必要に応じて後で読み込むことができます。

問題は、(実行時に) 属性名ごとに列を作成し、要求された属性に対応する列を取得するか、属性ごとにレコードを作成して、要求された属性のレコードを取得する方がよいかということです。

アプリケーションの性質上、どの順序で属性が読み取られるか、すべての属性が読み取られるかどうかは事前にわかりません。

スキーマのない財務データを扱うアプリケーションがあります。より正確には、シーマレス データは注文に関する情報であり、フィールドはマーチャントによってカスタマイズされます。一貫性と耐久性が重要です。

データが非常に動的であるため、報告は非常に困難です。各レコードはわずかに異なる場合もあれば、完全に異なる場合もあります。リレーショナル データベースを引き続き使用する場合、「ドキュメント」を BLOB としてシリアル化するしか選択肢がないように思われます。レポートは、おそらくユーザー定義レポートによって定義された共通構造にデータをコピーすることによって、個別に実行する必要があります (各「レポート」にはカスタム テーブルがあります)。

もう 1 つのオプションは、MongoDB のようなドキュメント指向の NoSQL データベースです。いくつかの調査を行った後、NoSQL データベースはACIDではなくBASEに依存しているため、ほとんどの人は NoSQL データベースを金融データで信頼しないようです。

私は、まったく異なる 2 つのユース ケースの真ん中にいるようです。私のデータはドキュメント指向データベース (MongoDB) に非常によく適合しますが、ACID データベースの信頼性が必要です。同時に、複雑なユーザー定義のレポートが必要です。

したがって、次の 3 つの選択肢があるようです。

1. 2 つの MySQL データベースを使用します。1 つはデータ (blob) の保存用、もう 1 つはユーザー定義レポート (多数のテーブル) 用です。
2. 大規模なデータベースをサポートしますが、グローバルな書き込みロックがあり、「最終的に一貫性がある」MongoDB を使用します。
3. MySQL を使用してデータ (blob) を保存し、それをレポート用に MongoDB にコピーします。唯一のインデックスがおそらくmerchantIDになるとすれば、これはどの程度うまく機能するでしょうか?

では、3 つのうちどれが私の最良の選択肢 (柔軟性と耐久性が最も高い) でしょうか? データの動的性を変更できないことを知っているので、考慮していない他のオプションはありますか? 本番環境でのレポート作成に MongoDB を使用している人はいますか?

(RDMS には MySQL を使用しています。MariaDB に切り替えることを考えています。選択したプログラミング言語は PHP です。誰かの名前を検索するような全文検索に Sphinx を使用することを考えています。)

C# で mongoDB を少し操作しましたが、コードはすべてまだ開発中です。新しいプロパティが作成、変更、および削除されるにつれて、時間の経過とともにドメイン クラスを進化させる際に、人々がどのような有用なパターンを発見したのか疑問に思っています。保存されているすべてのデータに対して更新を実行するか、ドメイン クラスが古い形式のレコードを処理する方法を知っていることを確認する必要があることは明らかですが、時間が経つにつれて、クラスが処理方法を知っている場合、これが混乱することは想像できます。すべての可能なフォーム形式。

私はこれを考えすぎていますか？これは主に、優れた防御的プログラミングを使用した場合にすぎませんか?

PHPを使用してMongoDBに画像ファイルを正常に保存しました。Mongodbから画像を取得するときに問題が発生しました。誰かが解決策を提供できますか？私のコードは次のとおりです。

生の半構造化されたスキーマのないビッグデータ入力 (HDFS や S3 など) を取得し、ほぼリアルタイムの計算を実行し、BI ツールにクエリまたはプラグインできる出力を生成できるテクノロジはありますか?

そうでない場合、少なくとも来年か 2 年以内のリリースに向けて取り組んでいる人はいますか?

私は MongoKit (v0.8.1) を使用していますが、 と を使用してドキュメントを定義するときの動作について少し混乱していuse_schemaless=Trueますuse_dot_notation=True。MongoKit は、db に保存するときに動的属性 (つまり、構造体 dict で定義されていないもの) を無視します。通常の角括弧を介してドキュメントにアクセスすると、期待どおりに機能します。明らかに、オーバーライドすることでこれを回避できます__setattr__が、少し予想外です。それともこれは意図的なものですか？ありがとう！

私は最近 MongoDB を扱っており、そのスキーマレス設計について学びました。しかし、私は NoSQL という用語と混同していますか? なぜそう呼ばれるのですか？SQL または SQL に似たクエリを使用していませんか?

主な違いはデータの保存方法にあるという記事も読みました。これは本当ですか？MongoDB の場合、JSON ドキュメントのように保存されます。

また、なぜ「NoSQL とリレーショナル データベース」が常に表示されるのか混乱しています。NoSQL データベースはリレーショナルではありませんか? MongoDB のドキュメントは、まだいくつかのキーを介して関連付け/リンクされていると思います (間違っている場合は修正してください)。では、なぜ非リレーショナルとラベル付けされているのでしょうか?

前もって感謝します！

スキーマレス データベース (特に CouchDB、Couchbase、MongoDB などのドキュメント指向データベース) を使用していて、特定のオブジェクトのデータ表現の形式を変更したい場合は、既存のレコードを古い形式のままにして、新しい形式で新しいレコードを作成することができます。これは、スキーマレス データベースの主な利点の 1 つとして宣言されています (ダウンタイムを回避できるためだと思います)。一方で、同じ種類のデータを多くの形式で処理するのは不便で非効率的です。では、スキーマレス データベースでデータをある形式から別の形式に移行するための適切なアプローチ/戦略は何ですか?

高速読み取りのためのアプリケーションのニーズによるデータの複製と、データの整合性のためのデータの関係と、複製されたデータへの変更の自動配布を組み合わせたNoSQLデータベースまたは「すぐに使用できるソリューション」はありますか？

例：

エンティティ：

ドキュメント/マテリアライズドビュー：

トピックのタイトルを変更すると、データベースレイヤーでこのプロパティを含むすべてのドキュメントに変更が配布されます。したがって、整合性はデータベースによって管理されます。

スキーマのない動作をするMongoDBが本当に好きなので、Oracleやその他のリレーショナルデータベースは解決策ではありません。