私は50以上の静的なページに育った古い静的なウェブサイトの新しいバージョンを作っています。ノードのファイルvsデータベースのコンテンツを配信
古いコンテンツのJSONファイルを作成したので、新しいWebサイトではCMS（共通ページ用のテンプレート）を使用できるようになり、バックエンドでDRYが増えました。
私はJSONからの私のビューにそのコンテンツを提供できるのだろうか、それともMySQLデータベースに入れなければならないのだろうか？
Node.jsを使用しています。ノードでは、JSONファイルをメモリに保存して、ユーザーがデータを要求するときにファイルの読み取りが行われないようにします。
これには正しい方法がありますか？キャッシュされたJSONファイルを処理するか、MySQLを使用して処理するかの違いはありますか？
ファイルは約400KBです。ファイルサイズが、1つのテクニックの選択に関連している場合は、
通常、データベースは頻繁に変更される動的コンテンツ、1対多または多対多の関係を持つレコードを処理するために使用され、さまざまな基準に基づいてデータをクエリする必要があります。
あなたが説明したケースでは、サーバーメモリにキャッシュされたJSONファイルで問題はないようです。ファイルの内容が変更されるたびに、つまりサーバーを再起動したり、http要求によるキャッシュの更新を開始したり、ファイルシステムレベルでファイルを監視したりして、キャッシュを更新するようにしてください。
それはさておき、あなたは、パフォーマンスを向上させるため、サーバー上やブラウザ上で静的ファイルのキャッシングを検討すべきである
app.use "/バウアー"、express.static（ "バウアー・コンポーネント"、{MAXAGE： 31536000を}）
Here私はこれを閉じるための票を参照してくださいブラウザのキャッシュ
なぜインダイレクションのレイヤーを追加するのですか？ JSONから直接ビューを提供してください。
これは、私はあなたが依然としてユーザーに同じ量のデータを提供していると思うだろうと思っています。mysql接続はafaikを少し遅くするだけです。しかし、私は間違っている可能性があります:) – Medda86
mysqlはディスクからのデータを提供しますが、これはRAMから提供するよりもかなり遅くなります。 – hd1
@ hd1いいえ、mysqlはRAM内のものもキャッシュします。実際の質問は、動的システム*をベースにするものではありません（ビューテンプレートが変更されたときにそのビルドプロセスの結果が異なるだけであっても、すべての要求に対してページを最初から作成するものです。一度静的なページを生成し、テンプレートやコンテンツが変更されたときに単にそれらを再生成するシステムを作成する方が良い選択でしょうか。 – Tomalak
今後データサイズが大きくならない場合は、RAM自体からjsonを直接提供することをお勧めします。将来的にデータが増加する場合は、最悪のアプリケーションケースになります。
400KBが小さいです。すべてのデータはRAMに保存されるため、I/Oは問題になりません。
動的にページを作成する - 広告を挿入する以外の理由がある場合、すべてのヘビーユーザーがそれを行います。 （私はそのような会社の腸で働いていましたが、何百万ものページが常に存在していましたが、静的なものはほんのわずかでした）
簡単に聞こえるカップルを選んでください。あなたがそれらに慣れることができるかどうかを確認してください。そして、それらの間を選ぶ。
Linux/Windows; Apache/Tomcat/nginx; PHP/Perl/Java/VB。繰り返しになりますが、あなたの快適さのレベルはこの小さなウェブサイトの重要な基準です。いずれもその作業を行うことができます。
どこが間違っていますか？私は悲惨にレンダリングが遅いWebページをヒットしたと確信しています。だから間違った方向に進むことは明らかです。あなたはすでにギアを切り替えています。あなたの決定が完全ではないと判明した場合、今から1年または2年後にギアを切り替える準備をしてください。
EAV（キー/バリュー）スキーマには重すぎるCMSは避けてください。 400KBのデータに対しては正常に動作するかもしれませんが、スケーリングには醜いです。すでにJSONとしてあなたのビューを保存し、ノードを使用している場合、それはMEANスタック（MongoDBは、エクスプレス、角度、ノード）を使用して検討する価値があるかもしれ
：
このようにして、MongoDBのドキュメントストアを含めて、JSのすべてをコーディングできます。 私は自分自身を使用していないことを指摘しておきます。
MySQLはJSONを問題なく保存して処理することができますが、構文解析しないため、コンポーネントに分割してドキュメント内のインデックスを作成することが不可能に近づかない限り、非常に柔軟性がありません。
これを行う必要があるかどうかは、個々のプロジェクトと進化する可能性があるかどうかによって異なります。
ウェブサイトの新しいバージョン（CMSを使用）を実装しているので、それが生きており、成長や変更の可能性があり、おそらくMySQLにJSONを保存することは将来の問題を蓄積していることを示唆します。実際にファイルが1つだけの場合は、ファイルシステムから取り出してRAMにキャッシュするほうがおそらく簡単です。
以前私のプロジェクトのためにMySQLにJSONを保存していましたが、いくつかのニッチのケースではコンポーネントデータの分割が終了しました。
新しいページを（m）追加する予定がない場合は、最も簡単な解決策に進んでいます.JSONを一度メモリに読み込んでからメモリから配信します。 400KBは非常に少ないメモリです。
データベースを含める必要はありません。確かに、あなたはそれをすることができますが、ここでは過剰です。
ビルド時に静的なHTMLコンテンツを生成することをお勧めします（gruntまたは..を使用してください）。変更を適用する場合は、ビルドを開始し、静的コンテンツを生成して展開します。
程度の良い品です。それは、完全性の相違が十分ではなく、その個人的な意見はどのような方法を取るかということですか？ – Rikard
これは、タスクを解決する多くの方法があることを意味します。どちらが最適かは、自分のスキルや好みなど、あまりにも多くの要素に依存します。より広い公衆に適用されるそのような質問のための単一の答えはありません。 – Tomalak
@Tomalak私は、この質問をより良く答えることができるように絞り込み/決定することができる要素は何でしょうか？ – Rikard