問題タブ [data-storage]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
4 に答える
1707 参照

c# - データベースは、C#アプリケーションのデータストレージに適していますか?

私はC#アプリケーションを開発しており、これらの仕様に適合するデータストレージに最適な選択肢を確実に選択したいと考えています。

プログラムには無限の量のデータを含めることができますが、そのデータは、アプリケーションを使用している1人のユーザーによってのみ使用されます。アプリケーションを閉じるたびにデータを保存する必要があり、アプリケーションの起動時にデータをロードする必要があります。

私はデータベースを見てきましたが、どれが私のニーズに最も適しているかわかりません。また、上記の仕様でデータベースが必要かどうか疑問に思います。おそらく、シリアル化と逆シリアル化を実装するバイナリファイル/XMLファイルを使用する必要があります。

私を正しい方向に向けてください!

ありがとう、OC

編集:私が含めるのを忘れた重要な要素の1つは、1人のユーザーが入力したすべてのエントリを保存し、アプリケーション/ユーザー間で簡単に共有できる外部ファイルにエクスポートできるようにする必要があることです。

0 投票する
6 に答える
4375 参照

c# - .NET データ ストレージ - データベースと単一ファイル

1 人のユーザーが顧客と求人サイトに関する情報を入力できる C# アプリケーションがあります。情報は非常に基本的なものです。

  • 顧客: 名前、番号、住所、電子メール、関連する求人サイト。
  • 勤務地: 名前、場所。

このプログラムに必要な仕様は次のとおりです。

  • 入力データ量に制限はありません。
  • アプリケーションごとに 1 人のユーザー。同時アクティビティや複数のユーザーはありません。
  • アプリケーション/ユーザー間で簡単に共有できる外部ファイルにユーザー エントリ/データをエクスポートできるようにします。
  • 顧客情報/求人サイト情報のさまざまな組み合わせに基づいて、ユーザー クエリが顧客を表示できるようにします。
  • データがアプリケーションの外部で表示または操作されることはありません。
  • プログラムはほとんど常に実行されており、タスク バーに最小化されています。
  • 起動時間はそれほど重要ではありませんが、クエリをかなり高速にしたいと考えています。

これはすべて、データベースを指しているように見えますが、非常に軽量です。ただし、データストレージに関して制限がないことも必要です。データベースを使用することに同意する場合は、私のニーズに最適なものを教えてください。データベースを使用する必要がないと思われる場合は、他に最適と思われる方法を提案してください。

0 投票する
2 に答える
2348 参照

database - ビデオ ファイルの保存場所 - データベースまたはディスク

ビデオ ファイルを BLOB オブジェクトとしてデータベースに保存するか、物理ディスクに保存することをお勧めしますか。

これは、ユーザーがビデオをアップロードして表示できる youtube に似たサイト用です。

データベースはMysqlになります

どちらのオプションが優れているか、またその理由

ありがとう

0 投票する
6 に答える
970 参照

xml - XMLの弱点は何ですか?

StackOverflowを読み、JoelSpolskyとJeffAtwoodによるポッドキャストを聞いていると、多くの開発者がXMLの使用を嫌うか、少なくともデータの保存や交換にXMLをできるだけ使用しないようにしようとしていると思います。

一方、私はいくつかの理由でXMLの使用をとても楽しんでいます。

  • XMLシリアル化はほとんどの現代言語で実装されており、非常に使いやすいです。
  • XMLシリアル化は、バイナリシリアル化よりも低速であるため、複数のプログラミング言語からの同じデータを使用する場合や、デバッグの場合でも人間が読み取って理解することを目的とした場合に非常に役立ちます(たとえば、JSONはより困難です)。理解するために)、
  • XMLはUnicodeをサポートしており、適切に使用すれば、エンコードや文字などの違いに問題はありません。
  • XMLデータを簡単に操作できるツールはたくさんあります。XSLTはその一例であり、データの提示と変換を容易にします。XPathはもう1つで、データの検索を簡単にします。
  • XMLは一部のSQLサーバーに格納できます。これにより、複雑すぎてSQLテーブルに簡単に格納できないデータを保存および操作する必要があるシナリオが可能になります。たとえば、JSONまたはバイナリデータをSQLで直接操作することはできません(ほとんどの状況でおかしな文字列を操作する場合を除く)。
  • XMLでは、アプリケーションをインストールする必要はありません。アプリでデータベースを使用する場合は、最初にデータベースサーバーをインストールする必要があります。アプリでXMLを使用したい場合は、何もインストールする必要はありません。
  • XMLは、たとえばWindowsレジストリやINIファイルよりもはるかに明示的で拡張可能です。
  • ほとんどの場合、XMLによって提供される抽象化のレベルのおかげで、CR-LFの問題はありません。

では、XMLを使用することのすべての利点を考慮に入れると、なぜ多くの開発者がXMLの使用を嫌うのでしょうか。私見、それに関する唯一の問題はそれです:

  • XMLは冗長すぎて、特にBase64エンコーディングに関しては、他のほとんどの形式のデータよりもはるかに多くの場所を必要とします。

もちろん、XMLがまったく適合しないシナリオはたくさんあります。SOの質問と回答をサーバー側のXMLファイルに保存することは絶対に間違っています。または、AVIビデオまたは大量のJPG画像を保存する場合、XMLは使用するのに最悪のものです。

しかし、他のシナリオはどうですか?XMLの弱点は何ですか?


この質問は本当の質問ではないと考えた人々へ:

1980年以降のコンピューティングにおける非クローズの重要な新しい発明のような質問とは対照的に、私の質問非常に明確な質問であり、他の人々がXMLを使用するときに経験する弱点と、なぜそれを嫌うのかを明確に説明するように促します。たとえば、 XMLが良いか悪いかについて議論することはできません。また、詳細な議論も必要ありません。したがって、これまでに受け取った現在の回答は短く正確であり、私が望む十分な情報を提供します。

しかし、この質問に対するユニークな良い答えはあり得ないので、それはウィキです。

SOによると、「実際の質問ではない」とは、「ここで何が質問されているかを判断するのが難しい。この質問は、あいまい、曖昧、不完全、または修辞的であり、現在の形式では合理的に答えることができない」という質問です。

  • ここで質問されていること:質問自体は非常に明確であり、上記のテキストのいくつかの段落はそれをさらに明確にしていると思います、
  • この質問はあいまいで、あいまいで、不完全です。繰り返しになりますが、あいまいでも不完全でもない、あいまいなものはありません。
  • または修辞的:そうではありません:私の質問への答えは明白なものではありません、
  • 合理的に答えることはできません:何人かの人々はすでに質問に素晴らしい答えを出し、質問が合理的に答えられることを示しています。

また、回答を評価し、受け入れられた回答を決定する方法も非常に明白なようです。回答がXMLの何が問題になっているのかについての正当な理由を示している場合、この回答が投票されて受け入れられる可能性があります。

0 投票する
1 に答える
50 参照

data-storage - メールサーバー/メールストレージに関する論文/最適化の概念はどこにありますか?

メールサーバー/ストレージの最適化手法について知りたいのですが。この情報はどこで入手できますか?GmailとOutlookはオープンソースではないことを理解しています。しかし、サーバー側で電子メールを保存する方法は、研究者やプログラマーがすでに対処できた問題です。そのようなものはどこかに公開されていますか?メールの送受信方法やMTAなどは気になりません。保存方法が気になります。ウィキペディアでは、転送プロトコルについてのみ説明していますが、ストレージについては何も説明していません。Plzは私にいくつかの記事を指摘します。

Thx、Venu

0 投票する
1 に答える
113 参照

python - SQLAlchemy:応答が送信された後にデータベースに書き込む

私はおおよそ次のことを行う簡単なサービスを持っています:

  1. HTTPクライアントがサーバーに接続します
  2. サーバーはクライアントのセッションIDとタイムスタンプをデータベースに書き込み、ほとんどの場合、空の応答を返します。

(実際の作業を行い、実際のデータを返す場合は、この質問とは無関係です)

この応答をできるだけ早く返すために、リクエストハンドラーの本体のmemcacheに情報を書き込み(memcacheは高速であるため)、SQLAlchemyを使用する別の関数が永続に書き込む別のスレッドを生成したいと思いますストレージ。このようにして、memcacheに書き込んでスレッドを生成した直後に戻ることができ、リクエストハンドラーはSQLAlchemyが情報をデータベースに保存するまで待つ必要がありません。

これは意味がありますか?はいの場合、どのように実装すればよいですか?

0 投票する
1 に答える
56 参照

c++ - S4sサーバーへのC++インターフェースが必要です

S4サーバー用のC++オブジェクトインターフェイスを持っている人はいますか?

0 投票する
2 に答える
619 参照

sql-server - 8060 Bデータページ(SQL Server)の8078バイト?

SQL Serverのデータは8K(8192 B)のページで書き込まれ、それぞれがデータ用に8060バイトで、残りはオーバーヘッド(システム情報)であることがどこにでも書き込まれます。

ただし、最近の記事[1]には、私が理解したように、8078バイトのデータが1ページに収まることが示されているコード例が示されています。

1ページあたり8,060Bを理解する上で何が欠けていますか?

x86 SQL Server2008R2でコードを確認しました...


アップデート:

[1]のフォローアップについての回答を見ましたか?私はそれを(私にとって)役に立ったとマークせず、すぐにコメントしたことを残念に思います...私は応答する前にもっと自分自身を調査したかっただけです...


Update2:

サブ質問を投稿しました[2]

[1]
テーブルの設計はSQLServerのパフォーマンスにどのように影響しますか?
http://sqlserver-training.com/how-table-design-can-impact-your-sql-server-performance/-

[2]
行あたり8060バイト、(varchar、nvarchar)あたり8000バイトの制限にするにはどうすればよいですか?
行あたり8060バイト、(varchar、nvarchar)値あたり8000バイトの制限にどのように到達しますか?

0 投票する
2 に答える
1781 参照

sql-server - SQL Server によるストレージの予約方法 そしてそれを覆す方法は?

SQL Server がどのようにスペースを割り当てて予約するかを理解しようとしています。

記事「テーブルの設計は SQL Server のパフォーマンスにどのように影響しますか?」の例を実行しました。[1]、記事[1.1]の結果を流用した結果[My 1.1]を受け取りました。
なんで?

あるケースでは余分なスペースが予約/割り当てられているのに ([1] のすべてのケース)、別の [My 1.1] ではそうでないのはなぜですか?
([1] では、どちらの場合も余分なスペースが予約されていることに注意してください。ただし、私のコンピューターではいずれかの場合のみ)

スペースはどのように割り当てられ、SQL Server によって予約されますか?
どうすればそれを制御/管理できますか?

[1] ======
テーブルの設計が SQL Server のパフォーマンスに与える影響は?
http://sqlserver-training.com/how-table-design-can-impact-your-sql-server-performance

【私の1.1
】以下の【1】から流用した私の結果

[1.1] 上記の鉱山から [1] を流用した結果


[1.2]
私の結果と一致する [1 ] の結果

0 投票する
2 に答える
4597 参照

sql-server - 行あたり8060バイト、(varchar、nvarchar)値あたり8000バイトの制限にどのように到達しますか?

私の質問「8060Bデータページ(SQL Server)の8078バイト?」から、MSSQLServerのページあたり8078バイトのデータを取得する方法が説明されました。

インデックス付けされていない固定サイズタイプのレコードの1つの列を持つ1行のみのデータストレージ(オーバーヘッドなし)に使用されるページあたりのバイト数を計算すると(MSDNの記事「ヒープのサイズの推定」に従って)、次のようになります。 〜8087バイト(ページあたり)。

1000ページ以上の本を購入して勉強せずに、行あたり8060バイト(他の質問の回答で言及)および(varchar、nvarchar)あたり8000バイトの制限に到達するにはどうすればよいですか?

私は確かにストレージ割り当てに何かが欠けています:管理するチャンクが少ないほど、オーバーヘッドが多くなります...