我是系统设计新手，被要求解决问题。
给定一个汽车租赁服务网站，我需要开发一个新功能。
该公司已经提出了一些他们想要捕获和分析的更多数据以及他们已经拥有的数据。
这些新数据可能类似于组装汽车的时间和成本。
我需要了解以下内容：
1：从 API 设计的角度来看，我应该如何解决这个问题？
2：如果可以的话，更改表的架构会有什么好处吗？
3：可以使用哪些数据库？
可以更改存储后的值。例如，组装时间可以减少或增加，因此用户应该能够更新值。
【问题讨论】：
标签： database database-design architecture
为了回答你的问题，我们把它分成两部分，理想架构和问答
架构：
一个典型的系统由多种技术组成，共同解决一个实际问题。问题可以通过多种方式解决，并且可能有不止一种解决方案。我们不是在这里谈论任何架构的效率和有效性，因为它是一个全新的主题来探索。但是选择最适合您的用例总是明智的。
由于您已经构建了现有的软件，因此遵循现有的设计模式总是有帮助的，这将帮助您详细了解现有代码并允许您创建非常适合并实际有助于集成功能而不是与之对抗的逻辑块它。
既然这清除了预规划阶段，让我们讨论一下这会如何影响我认为最适合您的用例的解决方案。
问答
1.从 API 设计的角度来看，我应该如何解决这个问题？
会有很多假设，除了由 api 组成的较少系统之外，任何东西都应该在需要时具有基本的身份验证和授权功能。除此之外，尽量坚持完整的 REST 规范，这将允许 API 使用者遵循标准路径，并且在决定端点是什么样子以及他们对使用者的期望时，集成的影响最小。
无论如何，并非所有系统都适合这种用例，因此系统设计人员有多少系统与标准实践兼容。
当新版本的 api 将具有 api/v2 时，名称约定很重要 路径和具有 api/v1 的旧路径，这是路由的好习惯 新功能。这允许系统无缝扩展。
2：如果可以的话，更改表的架构会有什么好处吗？
短期内，当您没有太多数据时，迁移数据相对容易。当它变得巨大时，它会更加痛苦和资源密集。
良好的做法可以让您防止出现您可能不需要迁移数据的情况。
当潜在的数据结构快速增长并需要注意时，数据库规范化变得如此重要。
无论使用任何 sql 或 nosql 解决方案，良好的数据结构总是对数据管理和编程实现都有帮助。
在我看来，让数据结构接近完美总是一件好事 想法，因为它会降低未来的迁移成本和 它带来的挫败感。还有一些用例需要添加 列，只要没有太多就可以添加它们 对现有代码的影响。否则它总是可以在 其他字段的单独表格。
3：可以使用哪些数据库？
通常任何 rdbms 都足以完成此类任务。当您看到大型数据创建者仍在集群中使用 mysql 的案例研究时，您可能会感到惊讶。
所以答案是，只要您有正常的场景，请继续选择您选择的任何数据库，直到您达到其单实例可扩展性限制。对于小型到模组规模的应用程序来说，这些限制是相当大的。
【讨论】：
从 API 设计的角度来看，我应该如何解决这个问题？
设计一个适合其需要存储的数据的良好数据模型。 API 设计将遵循数据模型。
如果可以的话，更改表的架构是否有好处？
新数据是否属于现有表？那么也许你应该把它存储在那里。除了：您可以在不破坏任何现有应用程序的情况下添加新列吗？也许你可以，但你需要进行回归测试以证明它可能会破坏你的时间表。单独的表可能是更安全的选择。
可以使用哪些数据库？
您对所处理数据的性质相当模糊，但它似乎是结构化的（数字？）。因此，这表明具有强数据类型的 SQL 将是最合适的。除此之外，使用当前正在使用的任何数据平台。部署不同产品的复杂性和麻烦将一扫而光。
最后一句话。与您的老板（或为您安排此任务的人）讨论这个问题。不要依赖互联网上一些随机陌生人的意见。
【讨论】：