異なる長さの文字列 (空の文字列の可能性があります) はデータベースに保存する必要がありますか?
オンライン ショッピング Web サイトを構築しています。各ユーザーはショッピング カートを持ちます
ショッピング カート (カート) には、
このショッピングカート(カート)に保存されているデータ構造は配列です(私はjson形式で保存しました)
ただし、一部のユーザーが物を配置しているため、各ユーザーのショッピング カート データの長さは異なります
ショッピング カートの内容 (Json データ) をデータベースに保存するべきですか、それともファイルとして保持すべきですか?
データベースとして保存する場合は、ユーザー .cart に保存しますか?カートに入れますか?
1) カートに入れた場合、システムはユーザーがカートに商品を追加するまで待機し、データをカートに追加し、ユーザーの user.cart_id をカートに割り当てます。 .id
ユーザーが Cart.item、user.cart_id=0 をクリアし、対応する Cartrow を削除すると
2) user.cart に保存された場合、各ユーザーには保管用の長いカートが割り当てられます。リソースの無駄ですか? (データベースの保存形式がわかりません...)
3) ファイルとして保存する場合、各ユーザーが正常に登録された後に $userid.json を生成し、プライベート ファイル内に置きます。フォルダーにアクセスできるのはサーバーのみで、中身は空の可能性があります
通常、Web サイトのショッピング カートはセッションまたは Cookie によって保存されます。
この方法の方がパフォーマンスがわずかに優れているためです。
一般的なウェブサイトのショッピングカートはセッションまたはCookieによって保存されます。
この方法の方がパフォーマンスがわずかに優れているためです。
登録が必要なユーザーは、最後にログインしたときにショッピング カートにアクセスできる必要があります。
登録していないユーザーはセッションに書き込まれます
1. セッションをデフォルトのファイル モードからデータベースに変更します。モード
2. json を使用せずに $_SESSION を直接操作します
3. 「登録ユーザーは最後にログインしたときにショッピング カートにアクセスできる必要がある」という要件を満たすために、ユーザー名 (ユーザー ID) フィールドをセッション テーブルを作成し、セッション コールバック関数を適切に調整します
つまり、
未チェックの情報を保存するためにデータベースの使用を検討する場合、セッション テーブルはすでに完成しています。もうそれを行う必要はありません
未チェックの情報を保存するためにファイルを使用することを考えている場合、単一のレイヤーでは膨大な数のアクセスが遅すぎるため、複数のレイヤーのディレクトリ ファイルを管理するのは困難です。どうしても必要な場合以外は採用しないでください
1. セッションをデフォルトのファイルモードからデータベースモードに変更します
2. $_SESSIONをjsonを使わずに直接操作します
3. 「登録ユーザーはアクセスできる必要がある」という要件を満たすため、前回のログイン時のショッピング「Car」は、セッション テーブルにユーザー名 (ユーザー ID) フィールドを追加し、セッション コールバック関数を適切に調整できます
したがって、:
未チェックの情報を保存するためにデータベースの使用を検討する場合、セッション テーブルにはすでに行われて。もうやる必要はありません
ファイルを使って保存することを考えたら…
この方法は非常に面倒な気がします
セッションを使用する場合、ユーザー A が Web サイトにログインし、項目をセッション 1 に保存します
その後、ユーザー A が変更されますブラウザで Web サイトにログインし、新しいセッション 2 を作成しますが、セッション 2 にはセッション 1 のコンテンツが含まれていません
ログインするたびに、ユーザー テーブルのセッション ID を設定する必要がありますか?
この場合、セッションは期限切れにならないように設定する必要があります。
誰かがそれを取得した場合、ユーザーのアカウントとパスワードは、そのユーザーのパスワードを変更した場合、そのセッションもリセットする必要がありますか?さらに面倒
登録ユーザーのカート情報は消失しないのでセッションは切れない
ただし、匿名訪問者のセッションは一定期間後にクリアする必要がある これをどう判断するか…
Json は、Ajax を使用して動的なショッピング カートを作成したいと考えています...
小さな Web サイトには合計 7 ~ 8 ページしかありません
この問題に遭遇したときの従来の解決策が何であるかを知りたいだけです
セッションを感じています。登録ユーザー情報の保存には適していません..
これは非常に危険です
プログラムのためにプログラムを書くのではなく、それが自分のスキルを向上させるために行うことです
実際の仕事をするときに、ビジネスプロセスを明確にせずに技術的なプロセスを考慮するのは間違いです
いくつかの間違いについてのみ話しますあなたのアイデアに
1. なぜショッピング カートのデータを保持するためだけに保持しなければならないのか理解できません
実際、ほとんどの人は、再ログインまたは切断した後にショッピング カートをクリアしなければならないという事実を受け入れています。 2. アカウントとパスワードは、ショッピング カートのデータよりもはるかに重要であり、ショッピング カートのデータよりも重要です。馬
アカウントのパスワードを紛失した場合、硯の中にコンドームやペン、インク、紙が入っているかどうかを他人に見られるのは心配ありませんが、私の配送先住所や荷受人の情報が他人に見られるのは心配です
3.全ての問題はプログラムで解決しなければならない
ビジネスロジックで解決すべきことは、決して実現しない技術ロジックが背負う ビジネス(物事を行うこと)のパフォーマンス
ショッピングカートのデータは、買い物完了後の一時的なデータです(re. -選択も完了したとみなされます)、データは役に立たないですか? それとも注文データに変換されますか
今の最大の違いは時間だけです、それだけです」 「プロセスを完了」と複数の閲覧の問題。ショッピングカートに入れたまま数か月保管しても役に立ちますか?
テクノロジーが限られている場合は、問題を複雑にしすぎないでください。それができない場合は、それをビジネス ロジック層に任せてください。さらに詳しく言うと、別のビジネス ロジックの側面について説明します。 問題:
私の家族と私 (おそらく 3 人以上) がショッピング アカウントのパスワードを共有し、複数のポイントで同時にログインし、買い物をして発送します。別の場所または同じ場所(順序が異なる)の場合、技術レベルで解決するにはどうすればよいですか?注: 2 番目のログインの拒否は、技術レベルのロジックではなく、ビジネス レベルのロジックです。つまり、複数のログインを許可する方法についてです。
需要分析には時間を掛けた方が良いです
事業部門とのコミュニケーションが最も重要です
それは自分のレベルを上げるために行うことです
あなたの考え方のいくつかの間違いについてのみ話します
1. あなたは、なぜショッピングカートのデータを保持しなければならないのかを理解していません。
実際、ほとんどの人が再ログイン/オフラインショッピングを受け入れています カートが空になったことを理由に苦情を言う顧客はほとんどいません
2. 「誰かがユーザーのアカウントとパスワードを取得した場合.. ." では、アカウントとパスワードはショッピング カートのデータよりもはるかに重要であり、本末転倒です...
さらに追加 アイテムをショッピング カートに入れる前に、ユーザーはアイテムの構成を選択する必要があります途中で考えていると、セッションが期限切れになり、再度ショッピング カートに商品を追加する必要があります。その時点で、ショッピング カート内の商品がなくなっていることに気付きます。別のオンラインストアに移動しますか?
あなたは 2 番目の点を明確に理解していませんでした。私が言いたいのは:
ショッピング カート (セッション) を永続的に保存する必要がある場合、誰かがログアウトせずに公共の場所にログインした場合、他の人は取得後に永続的にログインできます。セッションでは、パスワードを変更しても役に立ちません。ユーザーの許可があれば、さらに多くの情報を取得できます。 。
そして、あなたの質問はあまりにも突飛です。 。技術レベルで解決できることを技術で解決しなければならないというわけではありません
アカウントは一人にサービスを提供するだけです
複数の人が使用する場合、アカウントを持つことに何の意味がありますか? 。
1. 現時点でショッピングカートを保存してデータベースを使用するオプションを顧客に提供していますか?? 顧客が保存して再利用しない場合、これはあなたが他のウェブサイトの慣行を理解していないためです。 - 選択する場合は、お客様が責任を負い、継続的な閲覧セッションを維持します。Cookie を操作せずに 10 時間以上電話を切った場合でも、Cookie の有効期間はまだ残っています。私はよく Firefox を使って商品を選択し、IE オンライン バンキングに交換したり、翌日に購入したりします。 その間、ショッピング カートの保存操作を使用します
2. プライバシーを真剣に考えていないのは顧客の問題です。注文した商品を破棄せずにオンラインショッピングをするのは大嫌いです。パッケージをただ捨てる人にとっては、ウェブサイトが必要な警告とユーザー同意を提供するだけで十分です。また、一般データとログイン情報を完全に分離することもできます。 3. 私が提示した問題は、実際には意図したものではありません。テクノロジーを使って解決することもできますが(実際には解決することもできます。時間があるときに考えてください)、実際には多くの状況が起こり、テクノロジーだけで100%解決することはできないことを思い出してください。たとえそれを解決したとしても(アカウントの共有は一般的なことです、私の家族はこんな感じです、年老いたお母さんは登録方法を知りません、あなたは私のアカウントを使って注文し、私はその代金を支払います)、そしてそれ以上のものがあります。問題を解決するには、ビジネス レベルでいくつかのプロセスを標準化する必要があります。営業部門に相談してください。問題を解決する方法は、顧客体験のバランスを取ることであり、常に問題に主導されるのではありません。 7 階の snmr_com からの返信を引用します。プログラムのためにプログラムを作成しないでください。 . 自分のレベルを上げるためにやっている事です
実際の仕事をする際に、業務プロセスを明確にせずに技術的なプロセスを考慮するのは間違いです
あなたの考え方のいくつかの間違いについてのみ話します
1. 考えられなかったショッピング カートのデータを保持する必要がある理由はわかりません。保持するために保持するだけです。実際、切断後に再ログインしたり、ショッピング カートを空にしたりすることをほとんどの人が受け入れており、顧客からの苦情はほとんどありません。このため
2. 「誰かがユーザーのアカウントのパスワードを取得した場合…」、アカウントは…
上の階の人に、私は少しやりすぎているように感じますと言わせてください。 。
私は以前に C プログラムを書いたことがあり、メモリを無駄にするのが好きではありません。 。学校からこのプロジェクトの依頼を受けたのは今回が初めてで、私たちは PHP を学んで 1 週間も経っていません。 。
そこで、ショッピング カートの情報をデータベースに保存し、各情報に一定の長さを与えるかどうかを聞きたいのですが (ただし、長いものもあれば短いものもあります)
これはスペースを無駄にしますか?
ファイルに保存されている場合はスペースを無駄にすることはありませんが、vchar に保存されている場合はスペースを無駄にしますか?
長い間話した後、私はただ下調べをしていたことが判明しました
データベースの消費は別の問題です
ストレージ容量は重要ではなく、すべての SSD が使用されるわけではありませんが、情報/トラフィックの量は重要です
BS システムの唯一の問題 コストは簡単ですが、BS が考慮しているのは何千もの同時接続のコストです。そのため、最も重要なことは、必要な場合にのみ実行することです。さらに重要なのは、顧客が必要な場合です。製品を見るのではなく、製品名をロードしてそれが何であるかを知らせるだけで十分です。データベース内の製品の情報を読む前に、製品の特定の情報を確認するまで待ってください。
データベースの知識とその他の専門家。ガイダンス、私の弱点
さて...産業プロジェクトのクラスで...先生がランダムに数人の顧客を見つけたので、クライアントのプロジェクトをやらせてもらいました...
しかし、それはまだ実際のウェブサイトであり、使用されます完成後
ドキュメント、ユーザーマニュアル、スピーチなども含まれます
給料はありません...私たちはまだ支払わなければなりません..顧客も支払わなければなりません..OTZ
素晴らしい人たちがたくさんいます。
私も同じようなウェブサイトを作りたいです。
マークを付けて後で読みます。
私はまだ「PHP と MySQL Web 開発」という本を勉強中で、半分まで読みました。