用户需要创建适用于其他用户访问该组的动态规则
好吧，这就是“简而言之”我想要完成的事情......
我的应用程序的用户可以去创建一个新组。他们可以指定有关其他用户的标准，他们将允许/拒绝这些标准来确定允许谁加入该组。
例子： 年龄：12-16岁 高度：5 - 6 英尺
存储规则的数据表如下所示： 允许或拒绝标志（是/否） 开始年龄：12 年龄结束：16 起始高度：5 HeightEnd: 6
然后，我们需要检查用户是否符合条件，以确定是否允许他们加入该组。
这有道理吗？ 也可能有违背它的异常规则...... 例如，第一个“允许：Y”可能是 12 至 30 岁，但第二条记录可能会添加到“拒绝”年龄 25 至 28 岁，因此用户必须满足这两个条件才能进入。
有这方面的人吗？
Okay so here is "in a nutshell" what I'm trying to accomplish...
Users of my application can go and create a new group. They can specify criteria about other users which they will allow/deny to determine who is allowed to join the group.
Example:
Age: 12 - 16 yrs old
Height: 5 - 6 feet
The data table that stores the rules would be like:
Allow or Deny Flag (Y/N)
AgeStart: 12
AgeEnd: 16
HeightStart: 5
HeightEnd: 6
We would then need to check if the user meets the criteria to determine if they are allowed to join the group.
Does this make sense?
There can also be EXCEPTION rules which go against it...
such as first "Allow: Y" might be Ages 12 to 30 but a second record might be added to Deny ages 25 to 28 so the user would have to meet both criteria to enter.
Any takers on this one?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，您可以使用任何对您有意义的 DSL 将规则存储在数据库中，但 SQL 并不是解释或执行规则的解决方案。
将规则字段提取到您的应用程序中并在那里解释它会容易得多。您将可以访问功能丰富的解析器库来解释规则，以及编写 OO 代码来应用它的更简单的方法。
由于您只需要在用户尝试加入组时运行规则，因此运行查询来获取规则定义不会产生很大的性能成本。与尝试在 SQL 中实现规则解析器和执行器相比，它的成本肯定会低很多！
另一种思考方式是：数据库存储数据，而不是代码。您可以通过将规则的定义作为字符串存储在数据库中来捏造这一点，但让数据库将它们视为逐字字符串，而不是尝试将它们集成为 RDBMS 可以执行的代码。
Yes, you can store the rules in your database using whatever kind of DSL makes sense to you, but SQL is not a solution for interpreting or enforcing the rules.
It'll be far easier to fetch the rules field into your app and interpret it there. You'll have access to feature-rich parser libraries to interpret the rule, and easier ways to write OO code to apply it.
Since you only need to run the rule as a user tries to join a group, it shouldn't be a great performance cost to run a query to fetch the rule definition. It'll certainly be a lot less costly than trying to implement a rule parser and enforcer in SQL!
Another way of thinking about this is: a database stores data, not code. You can fudge this by storing the definition of rules as strings in the database, but let the database treat these as verbatim strings, not try to integrate them as code that the RDBMS can execute.