人们如何创建可重用的数据库？
人们如何创建可用于许多产品的可重用数据库？
例如，如果我们有一个为学校设计的数据库......可以轻松修改它以提供给大学吗？
如何创建一个可以作为产品的数据库，只需一次编码即可为许多客户提供解决方案？
谢谢
How do people make reusable databases that can be used for many products?
For example,if we have a database designed for a school...Can it be easily modified to be given to a college?
What is the way to create a database that can be used as a product to give solution to many customers with coding just once?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
通常，当人们这样做时，他们在同一行业中有多个客户。 因此，如果您是电子商务 Web 开发人员，那么您将一次又一次地遇到相同的产品、订单、订单详细信息类型的表场景。 当这种情况发生时，构建一个入门数据库就变得轻而易举了。
Usually, when people do this, they have multiple clients in the same industry. So if you are an ecommerce web developer, then you are going to run across the same products, order, order details type of table scenario over and over again. When this happens, it's a breeze to build a starter database.
对此没有简单的灵丹妙药。 您只需要保持数据库设计足够通用，但尽量避免过度通用化，因为这通常会导致维护方面的噩梦和其他令人讨厌的陷阱。
随着经验的积累，您将开始欣赏通用与专业之间的完美平衡。 这是可理解和可重用的代码/数据库设计的关键。
There's no simple silver bullet for this. You just need to keep your database design general enough, but try to avoid over-generalization as that usually leads to nightmares in maintenance and other nasty pitfalls.
With experience, you'll start to appreciate a perfect balance between generalized and specialized. That's the key to understandable and reusable code / database design.
答案是找到最佳位置。 wikipedia.org/wiki/Abstraction_(computer_science)" rel="nofollow noreferrer">抽象。
The answer is to find a sweet spot of abstraction.
第一步，与各种各样的潜在客户交谈，了解他们的需求、他们当前正在使用的产品以及他们希望当前产品能够实现的功能。 花在这方面的时间是你认为现在需要的时间的 10 倍。 在纸上画出潜在的 GUI，并让你采访的人查看图纸并提出建议。 如果可能的话，聘请一些业内人士作为业务分析师来帮助完成这一步。 询问法律要求。 有些行业存在很多法律合规问题，而另一些行业则没有。 例如，任何与医学界相关的事情，您都需要研究并充分理解 HIPPA 要求。
设计数据库结构和 GUI，然后让一些真实用户使用它。 根据他们所说的进行重构（令人惊讶的是，用户在需求收集中遗漏了许多直到面对实际 GUI 时才想到的东西）。
考虑所有潜在客户需要共同的内容以及您可能需要定制的地方 - 您的访谈应该在此处指导您。 决定如何处理定制。 或者即使你允许。 这可能在很大程度上取决于行业及其实践的标准程度。
如果这是盒式软件，则设计通常包括一个带有可自定义字段的表格，用户可以将这些字段添加到表单和报告中。
在基于 Web 的解决方案中，通常每个想要定制的用户可能都有自己的数据库，其中存储定制信息（以及用于不可定制事物的中央标准数据库），并且程序员根据客户的请求进行更改。 如果您采取这种方式，那么当您第二次为第二个客户端进行类似的自定义时，请考虑是否需要重构以使其成为每个人都可以使用的软件的新功能。 当客户可以用更少的钱获得标准报告时，无需编写 17 份仅存在一两个字段差异的自定义出勤报告。
在 Web 模型中，您还可以创建一堆模块，并让客户选择将哪些模块添加到他们的自定义解决方案中。 他们将根据他们选择的模块的数量和复杂性来付费。 因此，只需要三个标准报告的客户将比需要全部 27 个标准报告的客户支付更少的费用。当建议新的定制时，如果该建议似乎并不立即适用于其他报告，但该模块则需要支付开发费用，则客户需要支付开发费用。这样做是为了让其他人也可以购买。 如果其他人购买它，要求更改的原始客户可能会获得部分资金，直到支付开发成本。 他们还可能要求某些东西保留为自定义模块，并为此工作付出更高的价格。 我们有一些客户甚至不希望他们的数据与其他客户位于同一位置的同一服务器上。 不用说，我们做这样的事情会收取巨额费用。
定制成本高昂，并且可能会导致需要更多的程序员。 在走定制路线之前要仔细考虑。 它确实可以销售您的软件解决方案，但它的扩展性不佳。 当你有十个客户时，这还不错，但当你有几百个客户时，它可能很快就会失控。 一旦提供定制，就比稍后从标准套件中添加定制要困难得多。 通常，企业报告的组织中更需要定制。 如果您可以创建一个报告界面，人们可以在其中选择他们想要的信息并保存自己的自定义报告，那么您可以处理行业中的大部分自定义需求，而无需进行全面自定义。
Step one, talk to a very wide variety of the potential clients and find out their needs, what they are currently using and what they wish their current product(s) could do. Spend 10 times as long at this as you think you need to right now. Draw out a potential GUIs on paper and have the people you interview look at the drawings and make suggestions. If at all possible, hire some people in the industry as business analysts to help with this step. Ask about legal requirements. Some industries have a lot of legal complicance issues and others do not. Anything related in any way to the medical world and you will need to research and fully understand HIPPA requirements, for instance.
Design the database structure and a GUI then get some real users to play with it. Refactor based on what they say (it's amazing how many things users leave out in requirements gathering that they don't think of until faced with an actual GUI).
Think about what needs to common through all the potential customers and where you might need customization - your interviews should guide you here. Decide how to handle customization. Or even if you will allow it. This may depend a great deal on the industry and how standard their practices are.
If this is box software, often the design includes a table with customizable fields that can be added to forms and reports by the user.
In a web-based solution, often each user wanting customization may have their own database where the custom information is stored (and a central standrad database for the noncustomizable things) and the programmers make the changes based on requests from the clients. If you take this route, the second time you do a simliar customization for a second client, consider if you need to refactor to make this a new feature of the software available to everyone. No need to write 17 custom attendance reports that vary only by one or two fields when the client can for less money have a standard report.
In the web model, you can also create a bunch of modules and have the clients pick and choose which to add to their custom solution. They would pay based on the number and complexity of the modules they choose. So the client that wants only three of the standard reports would pay less than the client that wants all 27. When a new customization is suggested, the client pays for development if the suggestion doesn't seem to immdeiately apply to others, but the module is done so that others can buy it as well. If others buy it, the orginal client who asked for the change might get part of the money until their development costs is paid. They could also require that something remain as a custom module and pay a much higher price for this work. We have some clients who don't even want their data on the same servers in the same location as other customers. Needless to say, we charge a huge premium for doing something like that.
Customization is expensive and can lead to many more programmers needed. Consider very strongly before you go the customization route. It can really be the thing which sells your software solution, but it doesn't scale well. It isn't bad when you have ten cutomers but when you have a couple of hundred it can get out of control very quickly. It is a lot harder to back off of customization once you offer it, than to add customization later from a standard suite. Often the need for customization is more in the organization of corporate reporting. If you can create a reporting interface where people can pick and choose what information they want and save their own custom reports, you might handle most of the customization needs in your industry without full-scale customization needed.
诸如此类的应用程序需要相当复杂的数据模型来满足要求。 不同类型的学校会有不同的要求。 大学可能允许您添加或删除课程，但小学通常不允许。 大学需要将课程安排到教室，而小学则需要将学生按年级划分，并根据可用空间和教师将年级划分到教室。
您的设计需要考虑预期解决的所有要求，然后实施这些要求。 程序越通用，就越难满足客户的需求。 问题说“编写一次代码”。 如果你想编写一个程序来解决每个学校的需求，它将需要数百个功能； 在某些情况下，一些学校需要与另一所学校相反的功能； 例如，一些学校需要强制每个科目或教室配备一名教师，而另一所学校可能需要多名教师。 您期望满足的要求越多，应用程序就会变得越复杂。
在工业中，大型应用程序往往是为了可以扩展而编写的。 提供了一组核心功能，但应用程序需要针对特定客户进行更改和定制。 这使得开发变得更容易，因为您不需要预测每一个需求； 事实上，在客户有这些需求之前，您不需要预测很多需求。 但通过“定制”，您不再只编写一次代码。
最重要的一步是提出一个足够灵活以供以后扩展的数据模型，但又不能太灵活以至于无法开发。 最困难的部分通常是正确确定关系的基数。 例如，您可能会说一个班级有一位老师。 然后当一个班级需要两名老师时，你就必须重写大量代码并修复大量数据。 这些类型的更改既烦人又耗时。 然而，只要程序员有足够的时间，最终你总是可以修复错误。
An application such as this would require a fairly complex data model to account for the requirements. Different kinds of schools would have different requirements. A university might let you add or drop courses, but an elementary school typically does not. A university needs to schedule courses into rooms, whereas an elementary school needs to put students into grades and split grades into classrooms based on available space and teachers.
Your design needs to take into consideration all of the requirements it is expected to solve and then implement those. The more generic you make the program the harder it is to satisfy your customers. The question says "write the code once". If you want to write a single program that solves every school's needs, it will need hundreds of features; in some cases some schools will require an opposite feature from another school; for example some schools will need to enforce one teacher per subject or classroom while another school might require multiple teachers. The more requirements you expect to meet, the more complex the application becomes.
In industry big applications tend to be written so that they can be extended; a core set of functionality is provided but the application is meant to be changed and customized for a particular customer. This makes it easier to develop because you don't need to anticipate every need; in fact you won't need to anticipate many needs until you have a customer with those needs. But with "customization" you are not writing code only once.
The most important step is to come up with a data model that is flexible enough to extend later on, but isn't so flexible that it is impossible to develop for. The hardest part is usually getting the cardinality of relationships correct. For example, you might say a class has one teacher. Then when it turns out a class needs two teachers, you have to rewrite a lot of code and fix up a lot of data. These kinds of changes are annoying and time-consuming. However, in the end you can always fix mistakes given enough programmer time.
我能给出的最好建议是建立最低公分母......
所以......将其编码为面向教育设施的项目:-)
the best advice I can give is to build to the lowest common denominator....
So....Code it as a project geared towards education facilities :-)
花时间考虑要存储的数据类型，对其进行抽象以使其可扩展，然后相应地构建数据库。 我不知道您是否可以像从代码中那样获得完美的重用，但是如果您提前计划，您可以构建一个可重用的数据库结构（您仍然需要修改各个组件）。
Spend time thinking about the type of data you want to store, abstract it in order to make it extendable, and then build your database accordingly. I don't know if you can get perfect reuse the way you might from code, but you can build a database structure (where you still have to modify individual components) that is reusable if you plan ahead.
这取决于您的需求。 例如，许多基于产品的业务数据库使用的格式包括：
在您的情况下，您可能有
这种通用表格式可以可在许多应用中重复使用。
It depends on your needs. For instance, many many databases for product based business use a format that includes:
In your situation you might have
This general table format could be reused in many applications.
这一切都在设计中。 在许多（如果不是大多数）情况下，数据库需要针对各个机构进行一定程度的定制； 但通用数据库可以提供基本级别的功能。 设计出足够通用的东西来满足许多基本需求是可能的； 但问题是，设计的通用性往往会导致高度复杂性。 例如，您可以将数据库设计为数据驱动型，以满足大量潜在用户需求； 但通常情况下，最好根据机构的个人需求定制架构。
在针对可重用性情况进行设计时需要进行重大权衡； 通常它们涉及时间和复杂性； 即，设计不可重复使用的东西更容易； 通常，在进行总体设计和使用它时花费额外的时间是不值得的。
It's all in the design. In many (if not most) cases, databases will need some level of customization for individual institutions; but generalized databases can provide a basic level of functionality. It IS possible to design something that is general enough to serve many basic needs; but the problem is that that generality of design tends to lead to high complexity. For example, you CAN design your database to be data-driven for a large set of potential user needs; but usually, it's just better to customize the schema to the individual needs of the institution.
There are significant tradeoffs involved in designing for a reusability situation; usually they involve time and complexity; i.e., it's easier to design something that is NOT reusable; and usually, the additional amount of time invovled in making the general design and using it is not worth the effort.
在数据库设计中找到通用性和特殊性之间的适当平衡，以便围绕它构建的应用程序能够解决目标市场中的足够问题，从而让他们都会购买它。
Find the right balance of generality and specificity in your database design so that the application you build around it solves enough problems in your targeted markets that they'll all buy into it.
每个客户都会使用所有功能，还是您正在尝试构建一款适合所有产品的产品？ 我总是发现，花额外的时间来规划和修改数据库以适应特定的应用程序在未来会得到回报。 使用简洁的数据库结构比尝试考虑每种可能性的数据库结构要容易得多。
如果我有一个类似的现有数据库或模板，我通常使用数据库建模工具，例如 this 修改它，然后使用生成 SQL 功能（在加载/保存下）创建实际数据库。
我最近学到的另一个为我节省了大量时间的技巧是将用于生成数据库的 SQL 保存为脚本。 如果我想设置一个新的数据库，我会对源代码进行任何编辑，然后加载页面。 例如，如果我想生成一个新的客户表，我加载 http://localhost/load .php?generate=客户。
希望能帮助到你！
Will each customer use all of the functionality or are you trying to build a a one size fits all product? I've always found that additional time spent planning and modifying a database to suit a particular application pays off in the future. It's much easier to work with a concise database structure than one where you have tried to account for every possibility.
If I have an existing database that is similar or a template I usually use a database modeling tool like this to modify it and then use the generate SQL functionality (under load/save) to create the actual database.
Another trick I picked up recently that has saved me a lot of time is to save the SQL used to generate the database as a script. If I want to set up a new database I make any edits to the source code, and then load the page. For example, if I wanted to generate a new customer table I load http://localhost/load.php?generate=customer.
Hope it helps!