最佳实践：数据库应用程序编程模式

到目前为止，我已经写了许多数据库（MySQL）Web应用程序，但是我始终认为我的结构有点笨拙。我想改善我使用的编程/设计模式，希望在这里提供一些建议。特别是，我找不到一种可以补充OOP方法的结构，该方法封装了数据库的实现（模式）。一世

认为我的问题可以用例子来最好地解释。我现在使用2种方法说我有一个发票对象/类：

首先是使用静态成员函数

class Invoice
{
   int id;
   string ref;
   int customer_id;
   date created;
   date due;

   static id create();
   static bool update(id, field1, field2, ...);
   static bool delete(id);
   static bool get(id);
};

第二种方法是将所有内容放入数据库对象中：

class Database extends ProprietaryDBConnecter, Singleton
{
   id createInvoice();
   bool updateInvoice(id, field1, field2, ...);
   bool deleteInvoice(id);
   bool getInvoice(id);

   id createCustomer();
   bool updateCustomer(id, field1, field2, ...);
   bool deleteCustomer(id);
   bool getCustomer(id);

   // etc...
}

我发现（SQL）成员函数与“视图”非常不同，因为“视图”确定了类需要具备的内容，因此似乎破坏了文档/视图的体系结构。

同样，这似乎效率很低，例如SELECT语句仅应选择所需的内容，但是Invoice中成员变量的存在似乎意味着“保证数据”。

不知道我是否清楚地解释了这个问题，对于这种体系结构/设计模式/已知方式还有哪些其他最佳方法？

感谢您的建议

database

— 杰克
source

Answers:

好吧，我想您可以使用ORM。

但实际上，数据库设计不应遵循OOP原则，而应遵循规范化之类的数据库设计原则。并且应该在数据库而不是应用程序中进行设计。并且数据完整性规则应在数据库级别而不是由应用程序强制执行。

我建议您阅读一些数据库设计书籍，然后再阅读有关性能调整的信息。

— 赫尔格姆
source

+1并非所有内容都必须为OOP（即使某些ORM相当不错！）

— Javier 2010年

O / RM很不错，但是使用它们并不意味着您不能遵循良好的数据库设计。

— BlackICE 2010年

@David，我同意在知道他在做什么的人的手中是正确的。我确实建议他看一下ORM，但实际上，如果您首先不了解数据库设计，那么ORM是一个危险的工具。

— HLGEM 2010年

很好的一点是，可以在数据库级别强制执行数据完整性规则。但是，有时候，如果规则可能会更改，则在应用程序中放置一些规则（例如“项目必须始终包含5个以上的团队成员”）是有意义的，只有应用程序会修改数据。

— 乔恩·昂斯托特

应用程序几乎永远不是修改数据的唯一对象。当有人需要快速更改大量数据以支持某些数据修复时，未放入数据库的业务规则往往很容易受到违反。

— HLGEM 2010年

我找不到一种结构来补充封装数据库实现的OOP方法

似乎您正在描述对象关系阻抗不匹配。

有许多事情可以解决这个OODBMS，ORM工具，大量的数据访问工具。

我认为存在如此众多解决方案的事实使我相信不存在One True Solution™。

因此，您可以选择自己喜欢的任何方向，因为有些人会讨厌它，有些人会喜欢它。

— 康拉德·弗里克斯
source

看起来更严格。

— 杰克2010年

如果您不想使用ORM包装器，请使用支持OOP样式存储的数据库，例如MongoDB。

MongoDB中（从“胡蒙戈我们”）是一个跨平台的面向文档的数据库系统。MongoDB被归类为“ NoSQL ”数据库，避开了传统的基于表的关系数据库结构，转而使用具有动态模式的类JSON文档（MongoDB称为BSON格式），从而使数据在某些类型的应用程序中的集成更加容易和快捷。 ..

— 乔什·K
source