当您考虑构建一个应用程序时，例如在Web上使用关系数据库，您首先考虑该数据库，然后将您的应用程序作为前端，还是考虑程序和对象以及数据库如何存储那些。我正在尝试改变我的思维方式，但它没有被点击(我不确定自己的评估是否正确。)
我曾问过其他Hibernate和nHibernate问题，但我试图将其确定下来。我倾向于首先从数据库方面考虑具有数据库的应用程序，然后再考虑该应用程序。在阅读了很多有关Hibernate的内容之后，似乎那些使用Hibernate的人的想法有所不同。他们似乎在考虑对象和类。他们和我完全相反。
并且在休眠状态下。如果我倾向于首先考虑数据库方面，那么在开始时是“坏”还是“错误”的心态？我只能找到使用Hibernate或其他ORM的一些一致的理由-性能，数据库不可知性，并且那里有所不同。我想使用Hibernate，但是我想正确地使用它。这似乎是一种完全不同的思考方式，而不仅仅是性能和数据库选择。
Related:
最佳答案
对于这个问题，您显然会得到很多不同的答案，但是我倾向于首先考虑数据库，然后基于该数据库构建对象。我认为以这种方式工作更容易，因为我可以可视化数据库模式(而且，很容易在数据库模式中显示关系)。 @Tdpi就在这里:您应该基于问题域进行设计-对我来说，这可以转化为数据库中的思考，但是对于不同的人而言，这是不同的。
对象之间的关系并不总是那么明显，因此很难绘制一个显示它们之间关系的图。使对象彼此继承(但可能在数据库端使用相同的表)会使事情变得更加混乱。就是说，在某些复杂的应用程序中，我同时完成了两个工作-例如，创建表，并同时创建了对象结构，其中多个对象从同一基础继承，并且所有对象都使用同一表。
DB-first的另一个论点是，大多数ORM层倾向于基于数据库模式生成对象，因此，如果您设计对象，然后尝试对数据库进行反向工程，然后让ORM生成对象，那么您就在做事倒退，几乎肯定不会以您最初在纸上设计的结果为最终结果。
如果您使用的是基于对象为您生成数据库的ORM，则最好以另一种方式进行此操作并首先设计对象。只要您正确地对问题域进行建模，那么如果首先构建数据库或对象，就没有那么重要了。
综上所述，推论是当我在设计应用程序的前端时，我用铅笔和纸来设计它，甚至不用考虑数据如何存储在后端(对象，数据库等)。我只是按照我希望它的外观和操作来设计界面。
接下来的工作是将用户界面连接到后端架构，这有时非常简单，有时又不是那么简单-但我发现这是构建最佳UI的方式。通常，我不会公开所有功能，或者只允许配置简单的设置(例如，即使后端也允许拒绝继承权限，也仅允许应用权限)。这意味着您的UI不会过于复杂，或者至少可以更轻松地构建第一个版本，但是您也不必局限于制作有限的后端，或者将来不必进行大量更改。
当您根据数据的存储方式或创建的对象来构建UI时，它看起来就像是程序员设计的UI。
关于database - 在构建应用程序时，您首先考虑数据库或对象吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/799680/