关系数据库应用程序

Question

在开发主要与数据库交互的应用程序时，有什么好的开始？该应用程序需要根据用户输入，排序和结构进行大量过滤。

Answer 1

最好的开始方式是弄清楚“用户故事”（或“用例” - 但“故事”方法往往真的很有效，并开始将股东拖入共享故事中......！ - ）;最重要的是，将数据库模式设计为​​可以找到的最佳规范化思想，以满足用户故事的所有数据层需求。

第三，您可以在模式之上绘制视图等图层;第四，可选地，可能存在于DB中的触发器和存储过程，以确保更高层的一致性和易用性（但是，无论DBA如何强烈推动您使用，都不接受他们保证他们是必须：它们不是 - 如果您的存储层在规范化方面设计得很好并且可能在顶层有用的视图，非存储层功能CAN总是驻留在其他地方，这是一个方便和性能的问题，而不是逻辑一致性，完整性，正确）。

我认为应该追求业务层和用户体验层。我意识到这是一个有争议的立场，但我的观点是用户故事（以及随之而来的隐含的业务规则）已经告诉你很多关于业务和用户层的事情 - 所以，“确定下来”（相对来说 - - 敏捷和“拥抱变化！”应该始终统治;-)数据存储层是下一个业务的顺序，并且可以而且应该在更高层之后进行精炼（“向下钻取”）。

Answer 2

当您到达数据库层时，您将希望通过存储过程处理数据库访问。这将有助于为SQL注入攻击提供额外保护，并使逻辑更改更容易推送到数据库层。

Answer 3

要记住的最重要的事情是，您在设计数据库时的第一次，也是最可能的第二次尝试将以某种方式出错。这可能听起来很消极，甚至可能有点轻率（这肯定更倾向于'敏捷'软件设计理念），但重要的是要牢记这一点。

当然，您仍然需要彻底地进行分析，尝试一次实现一个功能，但尝试首先使用所有图层。这样，当规格发生变化并且您更好地理解问题时，您将不必做太多的返工。一个人将大量数据加载到系统中，改变事物变得越来越困难。

这种方法的主要好处是可以快速找到设计中断的地方，而没有将设计层正确分开。我觉得非常有用的一个技巧是同时使用sqllite和mysql版本，因此可以在两者之间进行无缝切换。因为这两者使用了不同的SQL重点，所以它突出显示了层之间的耦合太紧的地方。

Answer 4

如果主要是用户与数据交互，您可以使用表单透视图进行设计。

1. 用户输入需要哪些表格？

2. 输出报告需要哪些表格？

一旦确定了，表单的使用将决定在幕后编码所需的业务逻辑。您将获取输入，创建一组过程或方法来处理它们，并输出必要的内容。一旦了解了输入和输出，您就可以轻松设计必要的功能。

Answer 5

问题的范围非常广泛。你期待我告诉我该怎么做。我只能做好告诉如何做事的工作。使用Hibernate / Spring进行调查。由于大多数操作看起来像查询db，hibernate应该有所帮助。确保表格已充分编入索引，以便在根据索引字段进行过滤时，查询可以更快地运行。挑战性的任务是设计您的数据库层，它将成为您的应用程序和数据库之间的粘合剂。将您的数据库层设计得足够通用，以便它可以根据您传递给它的参数构建查询。然后继续开发上面的表示层。逐层开发应用程序会有所帮助，因为它会强制您将db逻辑与表示逻辑分离。在开发db层时，假设不仅是您的表示层，而且任何客户端都可以调用它。这将帮助您设计可扩展且适应新要求的应用程序。 所以底线：从DB，DB整合层，Controller和最后的表示层开始。

Answer 6

出于讨论的目的，我将假设您正在使用没有预先存在的数据库的启动应用程序。如果这是假的，我可能会稍微调整步骤的顺序。

1 - 了解宇宙

首先，你必须了解周围的事物，这样才能真正理解你想要解决的问题。

• 用户故事或用例通常是一个很好的起点。从用户将尝试执行的任务开始，并评估他们可能的频率是一个很好的起点。我喜欢从屏幕模型开始，无论有没有与用户及时交手，我发现有一个屏幕给我们的团队一些非常有限的争论。
• 这个领域还有哪些其他工具？现在，在我看来，用户从不使用过一个工具，他们交换了很多。您需要了解用户使用的其他工具的两个主要内容：
• （1） - 它们将作为流程的一部分与您的工具一起使用？考虑直接的输入/输出需求 - 他们想要切割/复制/粘贴的内容是什么？ ？您可能希望使用特定格式提供哪些工具上传/下载文件，他们使用哪些工具以及您可能希望与其共享术语，布局，颜色编码，图标或其他GUI元素的工具。特别关注工具的边缘 - 我在最近的一个项目中遇到的真正问题是模仿以前工具的数据库。事实证明，我们有大规模的数据库转移，我们可能会更好地重新开始。
• （2）你在替换或竞争什么（如果有的话）？窃取好东西，倾倒并改善坏东西。询问用户总是最好的。如果你不能至少理解管理举措很重要 - 这个工具是否取代了可怕的遗留工具？它可能是遗留的，但可能有这样的One True Feature这些年来一直保持着这个工具......

在这个阶段，我发现事情真的很糊涂 - 有一些屏幕截图，一些写作，一些模式或ICD - 但不是一个真正的凝胶线索。

2 - 逻辑实体

或者至少那是OO书中所说的。

我不太关心我在这个任务上看到的所有写作 - 但我发现任何给定的系统，我都有一个我反复绘制的真实图表。它通常大约3-10个盒子，并且希望小于连接它们的指数级大量的线条。 w ^

您可以越早获得该图表。

如果它是UML，数据库逻辑模型，旧的东西，或者在餐巾纸的背面（只要餐巾用塑料覆盖并悬挂在每个人都可以看到的地方），对我来说无关紧要。 / p>

越早越好，正确 越好。

完成图表后，您可以开始进行可能更正式的后续工作。

我认为这是一个关于你是从数据开始还是从屏幕和业务逻辑开始的鸡蛋和鸡蛋问题。我知道您确实希望优化数据库大小和可搜索性......但是如果没有屏幕和界面让您对数据有所了解，您如何确切地知道数据库需要什么？

在实践中，我认为这是一个不断变化的循环。你到处都做了一点，然后你就改变了一切。

即使你没有做一个正式的敏捷生命周期，我认为你最好的选择是将设计视为敏捷 - 在你真正感觉它是“正确的”之前需要多次重复和论证。

Answer 7

一个良好的开端是熟悉Multitier architecture

然后设计表示层。

在您的业务逻辑层中实现所有逻辑

最后，您实施了数据访问层。

Answer 8

尝试使用比C ++更高效的东西设置原型，例如Ruby，Python，甚至可能是PHP。

当原型工作并且你看到你的数据模型没问题且查询太慢时你可以开始使用C ++。

但是正如你的问题表明你有更多的选择，那么数据，在这种情况下，脚本语言的速度应该足够了。