更好的黑名单设计

发布于 2024-10-09 11:42:17 字数 819 浏览 0 评论 0原文

我有 10-12 个项目需要在我的系统上维护一个阻止列表。哪种设计更好?这些是示例列,还有更多要阻止的项目。

表1
b_id
b_电子邮件
b_name
b_用户名
b_页面名称
b_word
b_IP
评论

表2
b_id
b_类型
文字
注释

基本上在表1中,每个被阻止的项目仅是1列中的值,其余都是NULL。 在表 2 中,每个被阻止的项目都驻留在唯一的列中,因此不存在 NULL。

还有其他可能的设计,例如每个项目都有单独的表,但是会有很多 tbs 只是用来保存阻止列表。


编辑:使用此数据是为了阻止用户执行某些活动。每个被阻止的项目都用在不同的地方。示例:

block_IP = 网站将根据检测到的用户 IP 阻止的 IP 地址列表
block_name = 用户不能用来注册的受限名字/姓氏列表
block_email = 用户不能用来注册的受限电子邮件列表
block_username = 用户无法用来获取配置文件名称的受限用户名列表
block_pagenames = 用户无法创建的受限页面名称列表
block_word = 用户不能在评论、博客等内容中使用的辱骂性词语。 这样的例子不胜枚举……

所以基本上这些都像单独的查找项目。在理想的情况下,我们将为每个项目都有单独的表。但我不喜欢有 20-30 个表来保存被阻止的项目值。应该是管理这一切的更简单的方法。唯一的问题是某些项目(例如 block_Word)可能会增长到数百万行,因为有很多单词可以在多种语言中被阻止。

I have 10-12 items which i need to maintain a blocklist for on my system. Which design is better? These are sample columns, much more items to block.

table 1
b_id
b_email
b_name
b_username
b_pagename
b_word
b_IP
comments

table 2
b_id
b_type
text
comments

Basically in table 1, each blocked item is a value in 1 column only, rest are all NULL.
In table 2, each blocked item resides in the only column so there are no NULLs

There are other designs possible too like separate tbl for each item but then there will be lots of tbs just to hold blocklists.


EDIT: The use of this data is to block users from performing certain activities. Each blocked item is used in differnt places. Example:

block_IP = list of IP addresses that the website will block based on detected user's IP
block_name = list of restricted first/last names users cannot use to signup with
block_email = list of restricted emails users cannot use to signup with
block_username = list of restricted usernames users cannot use to get a profile name
block_pagenames = list of restricted page names users cannot create
block_word = abusive words which users cannot use within content of comments, blogs, etc.
and the list goes on...

So basically these are all like individual lookup items. In an ideal world we would have separate tables for each item. But I dont like to idea of having 20-30 tables just to hold blocked items values. Should be an easier way to manage all this. Only issue is some items like block_Word can grow to millions of rows as there are a lot of words that can be blocked in many languages.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

东京女 2024-10-16 11:42:17

查看实体-属性-值方法或使用无模式 NoSQL 数据存储。

http://en.wikipedia.org/wiki/Entity-attribute-value_model

如果您正在中间层处理“阻塞”,则可以将列表作为序列化对象(例如 JSON)转储到表中。

我假设您正在尝试执行诸如访问控制列表之类的操作,这取决于您的平台,您可能能够找到一个插件。

Check out the Entity-Attribute-Value approach or use a schemaless NoSQL datastore.

http://en.wikipedia.org/wiki/Entity-attribute-value_model

If you're processing the 'blocking' in the middle tier, you can just dump the lists as serialized objects (e.g. JSON) into the table.

I assume you're trying to do something like access control lists, which depending on your plaform you might be able to find a plugin for.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文