mysql のテーブルプレフィックスは履歴のゴミ箱に捨てるべきです。-PHPチュートリアル-php.cn

1. テーブルの接頭辞は広く使用されていますが、役に立ちません。サーバーの使用はほぼ無料で、データも完全に無料です。 1 つのデータベースに 2 つのデータベースがあることに意味はありますか?
2. プログラミング、メンテナンス、データベースのメンテナンスに多大な迷惑をもたらします。マルクス主義や毛沢東思想と同じだ。害があるだけで利益はありません。

プレフィックスを使用しなければならない理由を誰が教えてくれますか? ?

みんなに答えてもらう必要はない、私が自分で答えます。 99.99% の場合、これは必要ありません。とにかく、一度も利用したことはありません。

調査したいのですが、テーブル接頭辞が必ず必要なプロジェクトは誰ですか?紹介してもらえますか？本当にテーブルプレフィックスが必要な人がいるかどうかを確認するための全国的なオーディション?

フォローしていただきありがとうございます。

ディスカッションへの返信 (解決策)

データベースが複数のデータベースをサポートしている場合、テーブルが 1 つしかない場合でも、テーブルを区別するのは意味がありません。

スペースを購入した人は、データベースを 1 つだけ作成できます。プレフィックスの追加は非常に便利です。作成者はこれらのユーザーを無視できません。

スペースを購入した人が作成できるデータベースは 1 つだけです。プレフィックスの追加は非常に便利です。作成者はこれらのユーザーを無視できません。

私は少なくとも 20 以上のプロジェクトを見て、使用してきました。接頭辞が必要になることはありませんが、すべてのプロジェクトには接頭辞があります。

一部の悪意のある高レベルのユーザーが推測できないようにするには?
オープンソース CMS には必然的にいくつかの抜け穴が存在します。複数のテーブルプレフィックスが追加の保護層を提供する可能性があります。
特定の機能を実装するために使用されますか?例えば中国語版・英語版？

投稿者さんも会社を経営されているようですね？
もう 1 つスペースを購入します。本当に実行可能なプログラムの場合、年間 100 元を支払う余裕はありませんか? お客様にこれを言えますか？
dede、Discuz!、wordpress を 1 つのスペースに置きたいだけです。将来的には Wiki と質問応答システムも追加したいと考えています。
あなたが販売しているシステムはこれをサポートしていませんか?では、なぜ無料のオープンソースシステムを使用せずに、お金を出してシステムを購入する必要があるのでしょうか?

元々無理な設定が多い。しかし、関係部門によると、これは歴史的遺産によるものであるという。

たとえば、コンピューター言語は多様です。実際、言語が本当に優れている場合は、1 つで十分です。

たとえば、システムの画像やアニメーションのサポートが不十分なのは、私たちがコンピューターで作業を始めたとき、エンジニアがテキストのみを考慮していたためです。必要なのは、画面に表示されるテキストだけです。画像アルゴリズムが登場したのはその後ですが、アニメーションアルゴリズムも登場しました。しかし、これらの後発のものはすべて、元々サポートされていないハードウェアおよびソフトウェア環境で生まれたため、ファイルが非常に大きくなり、使いにくくなりました。

これらの欠陥を変更したい場合は、基礎となる層を完全に再構築し、システムを再構築する必要があります。しかし、これらは不可能です。それで間に合わせてください。

mysql は実際にはデータベースとは何の関係もありません。テーブルサフィックスまたはテーブルインフィックスを実行することもできます。これは単なる命名規則であり、従うかどうかは自由です。

通常、スペースの料金は 100 元で、無料のデータベースが付属しています。1 つのデータベースに 2 つのデータベースを追加する必要がありますか?
もう 1 つスペースを購入します。本当に実行可能なプログラムの場合、年間 100 元を支払う余裕はありませんか?
ローカル開発の場合は、もちろん、必要な数のデータベースが必要です。

しかし、1 つのスペースがすでに使用されている場合、ルートモジュールの分割により、なぜさらに 1 つのスペースが必要になるのでしょうか?ああ、お兄さんも100元？

節約された 100 元で、コード保守の追加の労力とコストは 1,000 元以上になるでしょうか?

私のウェブサイト運営の目的は、ウェブサイトの構築方法を学ぶことではありません
したがって、お客様のメンテナンスの都合で複数のスペースに料金を支払うことは不可能です。実際、私が複数のスペースを持っている場合、それはとても大変になります。メンテナンスが面倒ですか？
さらに、各システムは独立して動作し、相互に干渉しないため、「余分なエネルギー」はどこから来るのでしょうか?

私のウェブサイト運営の目的は、ウェブサイトの構築方法を学ぶことではありません
したがって、お客様のメンテナンスの都合で複数のスペースに料金を支払うことは不可能です。実際、私が複数のスペースを持っている場合、それはとても大変になります。メンテナンスが面倒ですか？
さらに、各システムは独立して実行され、相互に干渉しないため、「余分な労力」はどこから来るのでしょうか?

テーブルのプレフィックスはプログラミングに問題を引き起こし、コードのメンテナンスに余分な労力がかかり、10,000 元以上のコストがかかります。
プレフィックスを使用しないと、平均的なプロジェクトで開発コストとメンテナンスコストが少なくとも 10,000 元節約されます。

あなたが言及したメンテナンスの問題や困難がどこに反映されているか知りたいのですが？
そして、すべてが同じ場合は もう 1 つスペースを購入します。本当に実行可能なプログラムの場合、年間 100 元を支払う余裕はありませんか? 、ライブラリに複数のプレフィックスが必要な場合、さらにいくつかのスペースを購入する必要がありますか?
接頭辞は単なる装飾ですか?

これらのテーブルがどの機能モジュールに属しているかを一目で区別できるようにプレフィックスを追加しました。そうすれば、テーブルを検索するときの範囲が狭くなり、テーブルを見つける時間がさらに短くなります。それらを山にして一つずつ探しますか？もちろん、シナリオが異なれば、要件も異なります。使用しないからといって、役に立たないというわけではありません。

プレフィックスを使用せずにさらにいくつかのライブラリを追加したとしても、前後のライブラリを削減するメンテナンスコストは低くなるでしょうか?

テーブルプレフィックスはプログラミングに問題を引き起こしません。特にカプセル化されたデータ層は簡単です。

テーブルプレフィックスはテーブル名のアセンブリを必要とするため、実行速度をわずかに低下させます。
テーブルプレフィックスはプログラムを汎用にすることができます。レベルが強化され、異なるアプリケーションで同じテーブル名が使用されないようにする必要がなくなり、システムの通常の動作に影響を与えることなく、テーブルのプレフィックスを簡単に置き換えることができます。別の設定シミュレートされたデータに切り替えるだけです
テーブルプレフィックスを使用しない場合は、データベースをバックアップし、テストデータが Web サイトに公開されないように注意する必要がある場合があります

もちろん、テーブルプレフィックスは仕事の便宜のために使用される単なる技術的手段。それを使用するかどうかはあなた自身の問題です

あなたには Java の経験があるので、Java が C++ から分離したときに C/C++ の外部ファイルインクルード (#include) を放棄したことも知っているはずです。計画的な授業であれば外部ファイルを導入する必要はないのではないかと考えました。しかし、物事は常に満足のいくものではなく、2 年目にそれを補う唯一の方法は、別のインポートを作成することです

テーブル接頭辞はプログラミングに問題を引き起こすことはありません、特にカプセル化されたデータ層は簡単です

テーブルプレフィックスが実行されます。テーブル名を一度組み立てる必要があるため、速度が若干低下します。テーブルプレフィックスを使用すると、異なるアプリケーションがテーブルプレフィックスを簡単に使用できないようにすることができます。プログラムの開発およびテスト中に置き換えられるデータ

は、システムの通常の動作に影響を与えることなく維持することもできます。必要なのは、シミュレートされたデータ

に切り替えるための別の構成を割り当てることだけです。テーブルプレフィックスがない場合は、データベースのバックアップが必要になる場合がありますので注意してください。 Web サイトに公開されているテストデータの数

もちろん、テーブルのプレフィックスは、作業の便宜のために使用される単なる技術的手段です。それを使用するかどうかはあなた自身の問題です

あなたには Java の経験があるので、Java が C++ から分離したときに C/C++ の外部ファイルインクルード (#include) を放棄したことも知っているはずです。計画的な授業であれば外部ファイルを導入する必要はないのではないかと考えました。しかし、物事は常に不十分で、翌年にはそれを補うために別のインポートを作成する必要がありました

PHP では、外部ファイルを手動で参照する必要がほぼ完全になくなりました。

あなたが言及したメンテナンスのトラブルや難しさはどこに反映されているのか知りたいですか？
そして、すべてが同じ場合は
もう 1 つスペースを購入します。本当に実行可能なプログラムの場合、年間 100 元を支払う余裕はありませんか? 、ライブラリに複数のプレフィックスが必要な場合、さらにいくつかのスペースを購入する必要がありますか?

接頭辞は単なる装飾ですか?

これらのテーブルがどの機能モジュールに属しているかを一目で区別できるようにプレフィックスを追加しました。そうすれば、テーブルを検索するときの範囲が狭くなり、テーブルを見つける時間がさらに短くなります。それらを山にして一つずつ探しますか？もちろん、シナリオが異なれば、要件も異なります。使用しないからといって、役に立たないというわけではありません。プレフィックスを使用せずにさらにいくつかのライブラリを追加したとしても、前後のライブラリを削減するメンテナンスコストは低くなるでしょうか?

プレフィックスが良くない理由は、テーブルを早く見つけるためだと思います。
接頭辞はテーブル名の読み方に影響します。
接頭語を調べ始めたとき、それらには何らかの意味があると思いました。結局それは無意味だったことが分かりました。それはただの接頭語です。

外部ファイルをインポートできるかどうかと、外部ファイルをインポートする必要があるかどうかは 2 つの異なるカテゴリです

プレフィックスの存在は早見表にあります。同じプレフィックスを持つものは同じアプリケーションに属している必要があります
プレフィックスは次のように理解できます。グループ (カテゴリー) のロゴ

存在には意味がある。
プレフィックスの存在は、異なるテーブル間の意味を素早く区別するためです。もちろん、区別する必要がなければプレフィックスを付ける必要はありません。
多分あなたはそれを無意味だと感じ、仕事に際限なく迷惑をもたらし、コストが大幅に増加するので、完全に放棄することができます。しかし、テーブル接頭辞が他の人の作業に多くの利便性をもたらす可能性があることをご存知ないかもしれません。
大規模なアプリケーションでは、相互に関連し、高度に結合されたリレーションシップテーブルが多数存在する可能性がありますが、それらは同じモジュールに属していない可能性があります。おそらく、プレフィックスの意味が反映されています。それ以外の場合、マルチデータベース操作の場合、テーブル間の関係もデータベース間の関係にアップグレードする必要がありますか?逆に、美しくない〜

ことわざにあるように、存在には意味があります。

数か月間考え、議論した結果、結論は次のとおりです。
1. 17階が正解です。 xuyanlu
2. 16 階の答えは良いです。
3階と6階の回答は20年前は正しかったかもしれません。今では完全に間違っています。

グループ化にはプレフィックスが必要ですが、テーブル全体にプレフィックスが付いており、これは完全に病的です。
xuzun のように、一日中インターネットでエクササイズをしている人々を考慮する必要はありません。だって、こんな人は中国全土探しても3人もいないでしょう？だから無視してください。