问题标签 [modeling]

我对这个讨论相当陌生，但即使冒着听起来“无知”的风险，我也必须提出这个问题。为什么我们现在对'DDD'如此强调。我对“DDD”的研究越多，我的应用程序似乎就越复杂。而使用数据库对我的域进行建模有助于使我的应用程序跨层保持一致。然后我可以使用 DAL Helpers（如 SubSonic 或 L2S）轻松访问该模型。这有什么不好？即使在企业应用程序中？

当我们有一个经过尝试和测试的方法时，为什么我们要努力创建一种新的域建模方法？

我愿意听取这里纯粹主义者的意见。

我正在建立一个在线商店来销售“绿色超大号 T 恤”之类的产品。即，同一件衬衫可以有多种尺寸/颜色，不同的组合可以售罄，不同的组合可能有不同的价格等。

我的问题是我应该如何在我的 Rails 应用程序中对这些产品进行建模（或者实际上如何在任何应用程序中进行建模）。

我目前的想法是：

因此，每个产品将具有一个或多个特性（例如，“颜色”、“尺寸”等），然后每个特性将具有一个或多个变体（例如，“红色”、“蓝色”等）。

这种方法的问题是我在哪里存储价格和库存？即，给定产品的价格和库存由其特征所采用的变体决定。（绿色可能比红色贵，大的可能缺货等）。

我的一个想法是给产品一个“base_price”，并让变体修改它，但这似乎过于复杂（并且可能不起作用）。

这就是通常设计课程的方式吗？一个类 = 1 个表。包含另一个表的外键的表怎么样？

假设我有以下内容：

好的做法是否包括为每个表创建一个类？如果是这样，在没有 orm 的情况下将此类类加载/保存回数据库的最佳实践是什么？一个简单的代码示例将非常有帮助

首先，我很抱歉这个问题的反馈性质。我试图尽可能地概括它，以便其他人也可以从中受益，但我真的没有人给我关于这个设计的反馈，所以我希望你们能帮助我。

话虽如此，我不想在我的数据库中对不同的用户类型进行建模。我想要共享用户类型的凭据。这个问题基本上是关于继承的，这是 RDB 做得不太好的事情。

然而我确实想出了这个设计： DB设计http://img48.imageshack.us/img48/9196/dbdesign.png

..但我不确定我是否应该对此感到满意。我不喜欢它的商业合同的数量。首先，我不知道哪个用户类型属于给定的凭证，这意味着我可能需要搜索 N 个表，其中 N 是我得到的用户类型的数量。因此，我想将用户的类型与他或她所在的角色联系起来。因此，如果具有凭据 A 的用户具有“UserType1”和“UserType2”的角色，我希望在 UserType1 和代表他或她的 UserType2 表。- 而且我不确定我是否喜欢这些“业务逻辑”-约束.. :)

非常感谢您对此给定设计的任何反馈，就像任何替代设计一样。

提前致谢

在我的在线商店中，每个订单都与一个送货地址和一个账单地址相关联（当然，它们可以相同）。这是我第一次尝试对此建模：

这工作得很好，但现在表单助手不起作用。即，form_for只会生成名称类似的字段address[zipcode]，所以我必须手动破解它来获取billing_address[zipcode]和shipping_address[zipcode]。

我想我可以使用单表继承将子类Address化为ShippingAddressand BillingAddress，但这对我来说似乎有点 hacky（并且与建模 Customer <--> Address 的最佳方式中的一些好的答案相矛盾）。

我们的客户希望我们构建一个基于 Web 的富 Internet 应用程序来收集软件需求。基本上，它是一个基于 Web 的案例工具，遵循特定流程从利益相关者那里获取需求。我是项目经理，我们仍处于项目的早期阶段。

我一直在考虑使用形式化方法来帮助我的客户和开发人员澄清对工具的要求。我所说的形式方法是指某种形式的建模，可能是基于数学的。我已经阅读并正在考虑的一些内容包括 Z ( http://en.wikipedia.org/wiki/Z_notation )、状态机、UML 2.0（可能带有OCL等扩展）、Petri 网和一些编码合同和前置条件和后置条件等级别的东西。还有什么我应该考虑的吗？

开发人员经验丰富，但根据所使用的形式，他们可能需要学习一些数学知识。

我正在尝试确定我是否值得在这个项目上使用形式化方法，如果是，在多大程度上。我知道“这取决于”，所以对我来说最有帮助的答案是是/否和支持论点。

如果你在这个项目中，你会使用正式的方法吗？

我要建立一个书店，其中我们有 3 个实体（类）：卖方、买方、图书。我将数据库设计为以下细节：
- 买家和卖家都可以分别购买/出售一本或多本书。
- 如果买家想卖一本书，他/她需要一个卖家账户。
- 买家将提供他们的价格，卖家想卖给最好的买家，我必须保存其中的所有信息。

我认为这会更好，但是如何开始使用价格优惠？
是的，我可以在流程类中添加一个报价，所以我改变了主意，这个模型就出现了：（对不起，描述太长了）

*Offer* 字段将被添加到 *process* 类中： ______ ______ _________ _______ |卖家| | 书 | |工艺 | | 买家 | -------- -------- ------------ --------- | 身份证* | | 出价* | | 身份证* | | 按ID* | | 姓名 | | XXX | --> | 标识 | | 报价 | | 日期&..| ------------ (*) 表示主键

由于这是我的第一次，我对数据库设计感到非常困惑。这会满足系统需求吗？如果没有，我怎样才能让它工作？如果有，有没有更好的设计？

任何建议表示赞赏，在此先感谢:)

更新- 我真的无法在这里选择最佳答案，一切都有帮助。很多很多谢谢你们。希望你最好^o^

我正在建模一个类图，我完全被这个问题所困扰：

我的新 Web 应用程序有“卡片”（关于主题的条目），用户可以修改，à là wiki。但与 wiki 不同的是，不同的卡片拥有不同的数据。与 wiki 不同的是，卡片与数据库中的其他卡片明确相关。让我向您展示我最初是如何使用一个虚拟示例设计它的：

优雅，干净，但错误。使用这种方法，博物馆与绘画版本相关联，而不是与绘画本身相关联。我想到的第一个解决方案是这个：

这种方法闻起来很臭。CardInfoVersion 下的类层次结构很大，因此 UML 模型将不可读，并且 Card 类将充满对 CardInfoVersion 子类的 ORM 引用。然后我想出了这个：

这也有气味。实际上，自从版本消失以来，这一切都搞砸了。它还要求管理员验证对卡片的提议修改。

我真的不知道如何解决这个问题。请记住：如果 CardInfoVersion 子类不相互关联，原始设计就可以了。

请帮忙！

This is vaguely related to:

Should I design the application or model (database) first?

Design from the database first through to UI or t’other way round?

But my question is more about modeling and artifacts and less about the right way to do design. I'm trying to figure out what sort of design artifact would best enunciate the link between features (use cases), screens and database elements (tables and columns, most particularly). UML is very code-centric. Database models are very database centric. And of screen designs are UI centric!

Here's the deal... my team is working on the first release of the product. We used use cases, then did screen designs and database design was somewhat isolated from the two. A critical area for bugs was the lack of traceability between the use cases and their accompanying screens and the database. In our product, there's a very high degree of overlap between use cases and database elements. Many use cases touch over 75% of the database infrastructure. So we have high contention over database design areas, and it's easy for a small database change to disrupt the lower levels of business logic.

For our next release, I want the developers and our DBA to have a really clear insight into what parts of the database each feature touches. The use case/screen design approach worked well, so we're keeping it... the trick is linking each use case and screens to the database model so the relationships are really obvious and hard to forget about.

On smaller projects (we're only 10 people, but often I've worked on teams of 3 or less), I've created my own custom diagrams to show this part of the design. Sort of a fusion of screen, UML and database table, done in Visio with no link to actual code or SQL. I'm not sure it will work for a larger team, as its highly manual to keep up to date, and it doesn't auto generate code the way our database modeling tool does.

Any recommendations? Is there a commonly accepted mechanism for this?

FYI - we're pretty waterfall, that isn't going to change any time soon. And we do love artifacts... Saying "switch to agile" is not a viable solution for our group.

是否有用于同步 POJO 属性的框架？例如，我想表达（以某种高级的、声明性的形式），foo.text = bar.text + baz.text或者foo.y = (max(bars, y)).y不必注册属性更改，元素添加和删除值和（尤其是）集合上的侦听器，这些是重复且容易出错的。