問題タブ [database-abstraction]

私はいくつかの「モデル」型クラスの上にデータベース抽象化のレイヤーを構築したい小さなphpアプリを持っています。

私は ezSQL_mysql を使用してデータベースの作業を行っています。

私の質問は、アプリを設計する最良の方法は何ですか? シングルトン パターンを使用して db 接続を共有する必要がありますか? 「モデル」クラスは ezSQL_mysql を拡張する必要がありますか? あるいは、私はここで完全に基地から外れており、何か他のことをする必要があるのか​​もしれません.

私が必要なのはこのようなものです

Controller.php

User_model.php

Sale_model.php

OOP の原則は、何らかの理由で Web 開発に適用できなかったため、理解するのが困難でした。より多くのプロジェクトを開発するにつれて、コードの一部で特定のデザイン パターンを使用して、読みやすく、再利用し、維持しやすくする方法を理解し始めたので、ますます使用するようになりました。

私がまだ完全に理解できないことの 1 つは、なぜデータ層を抽象化する必要があるのか​​ということです。基本的に、DB に保存されているアイテムのリストをブラウザに出力する必要がある場合は、次のようにします。

PDO の素晴らしさを説くハウツーや記事をすべて読んでいますが、その理由がわかりません。LoC を保存していないようです。また、上記で呼び出すすべての関数がクラスにカプセル化されているように見えますが、まったく同じことを行うため、どのように再利用できるかわかりません。私が PDO に見ている唯一の利点は、準備されたステートメントです。

データの抽象化が悪いと言っているわけではありません。現在のクラスを正しく設計しようとしていて、DB に接続する必要があるため、これらの質問をしています。これを正しい方法で行うと考えました。たぶん、私はこの件に関する悪い記事を読んでいるだけです:)

このテーマに関するアドバイス、リンク、または具体的な実際の例を本当に感謝します!

ScalaでJDBCResultSetのラッパーを作成します。
このラッパーは関数として使用することを目的としていますResultSet => ParticularType。
問題は、マルチマップを作成するための一般的な解決策が見つからないことです。

コレクションを取得する方法は次のとおりです。

次はマップの作成です。これはコレクション作成の実装であり、マップが非抽象的であるため抽象的ではありません（私の実装では常にHashMapでバックエンドされています）。
私の意見では、次のようになります。

それが機能する場合は、ListMultiMapの作成を次のように記述します。

問題は、その時点で宣言されていないため、でV使用できないことです。 抽象型は良い解決策だと思いますが、それらを正しく扱う方法がわかりません。Place for V

そのようなコレクションを作成する正しい方法は何ですか？

また、クラス階層の上位ですでに定義されている抽象型をオーバーライドできるかどうかもわかりません。

私はいくつかのデータベース抽象化レイヤーを使用していますが、それらのほとんどは、VARCHAR 250 である「文字列」や長さが 11 桁の INTEGER などの属性を使用しています。しかし、たとえば、250 文字未満の長さのものがあります。私は行ってそれを少なくするべきですか？それは本当に価値のある違いをもたらしますか？

前もって感謝します！

使用されている DBMS から独立してデータベース モデル (テーブルとビュー) を作成するためのソリューションがあるかどうか疑問に思っています。私は現在 Zend Framework を使用しており、基本的な CRUD 操作の抽象化は非常に優れていますが、テーブルとビューを作成するための抽象化は提供していません。一部の ORM フレームワークがこの機能を提供していることは知っていますが、残念ながら私の場合は ORM を使用できません。

ありがとう！

Android (または iOS) のアプリケーション開発で、Web サイトなどのどこかにホストされているデータベースから情報にアクセスする必要がある場合、一般的な方法は、データベースに接続するページ (私の場合は PHP ページ) を作成し、 JSON、または PLIST などを出力します。アプリケーションはそのページの URL にアクセスし、データを取得して処理を行います。

この方法を使用すると、アプリケーションのコードでデータベース セキュリティの詳細を明らかにすることなく、リモート データベースにアクセスできます。これは初歩的な抽象化レイヤーのようなものです。

この抽象化レイヤーを可能な限り柔軟に設計しようとしています。データを取得するページを作成し、それが現在のバージョンのアプリケーションで機能する場合は、すばらしいことです。しかし、将来のバージョンで何かを変更し、取得したデータを少し変更する必要がある場合は、別のページを作成する必要があります。そこに浮かんでいる私のアプリケーションの古いバージョンを破壊することを恐れて、古いページをそのままにしておく必要があります。

このような柔軟で将来性のある (可能な限り) 抽象化レイヤーを設計するための良いアプローチはありますか?

誠意を持って再利用できるオープンソースプロジェクトの下でこれまでに開発された最高のPHPDAL（データ抽象化レイヤー）は何ですか？

最も一般的なデータベースシステム（MySQL、PostgreSQL、MSSQL、Oracleなど）への抽象化を十分にサポートするDALをアプリケーションに選択するのは難しいと感じています。

1. 広くテストされ、
2. 優れたインターフェース（読み取り可能なメソッド名、優れたパラメーター受け渡し戦略）、
3. 速い、
4. 軽量、
5. キャッシュを提供する（たとえば、Memcacheと統合する、または優れたキャッシュメカニズムをサポートする）、
6. オープンソースライセンス、
7. 少なくともMySQL/MySQLi（非PDOベース）用のアダプターが必要です

考慮すべきライブラリのいくつか：

• PHPBB DAL http://wiki.phpbb.com/Database_Abstraction_Layer
• Joomla DAL http://api.joomla.org/Joomla-Framework/Database/JDatabase.html
• ADOdb http://phplens.com/adodb/
• Zend_db
• Doctrine（欠点はPDO_ *のみをサポートします）
• オープンソースプロジェクト/ブランチで使用/開発されたその他のDAL

考慮しないでください：

• PDO
• すべてのORM（ただし、DoctrineにはORM以外に個別のDALがあるようです）

次のようなことを行うことで、ドライバーを持っているデータベースへの複数の接続を作成できる学習目的で、データベース抽象化クラスを作成して遊んでいました。

また...

しかし、私はそれについて考えなければなりませんでした.ファクトリオブジェクトとの複数の接続を管理する必要がない限り、PDO の出現でこのようなものは本当に必要ありませんか?

私の質問は、PDO にさらなる抽象化レイヤーを追加することは有用だと思いますか? またその理由は?

MVC3/.Netアプリケーションのデータベースアクセスを処理するクラスを見ています。

このクラスは静的であり、一般的なDBクエリ（「GetColumnBValueForColumnA（）」などのあらゆる種類の厄介なものや、はるかに複雑なクエリ）に便利なメソッドを提供します。これは、特定のソリューションとドメインに対して適切に因数分解/最適化されています。

ただし、クラスを静的であると見なすと、これがどのように悪い考えであるか（おそらくマルチスレッドのコンテキストでは？）について、半分忘れられた記憶が引き起こされ、私はその気持ちを揺るがすことができません。

この種のクラスを静的に保つのは良い考えですか、それともデータベース呼び出しごとにインスタンス化する必要がありますか？

重複の可能性:
データ抽象化レイヤーとデータ アクセス レイヤーの違いは何ですか?

nettuts に関するこの記事を読んだところです。私はちょっと混乱しました。データ アクセス レイヤーとデータベース アブストラクション レイヤーの違いは何ですか?

また、これには独自のカスタマイズされたクラスを作成する必要がありますか、それとも PDO を使用する方がよいでしょうか?

DatabaseOpsすべての CRUD 操作を実行するクラスがあります。他のクラス (例: ユーザー) はそれを継承し、このクラスのメソッドを使用して CRUD アクションを実行します。接続を開く、接続を閉じる、配列をフェッチする、クエリを確認するなどの名前の別のクラスがDatabaseあります。それらを単一のクラス (データ アクセス/抽象化レイヤー) に書き込む必要がありますか? どちらが良いでしょうか？