访问查询 - 比较多个用户选择
我遇到了一个我似乎无法克服的概念问题。
假设我希望用户通过表单将他们当前穿着的衣服输入数据库。将“T 恤”和“蓝色”放在新的一行中非常容易。但是，假设我想将一个用户与其他用户进行比较，并按照从最相似到最不相似的顺序进行排名。
当您考虑到可用选项的数量时，这将成为一场巨大的噩梦。
- 汗衫
- 外套
- 夹克
- 围巾/项链
- 头饰
- 裤子 内衣
- 打
- 底裤
- 袜子
- 鞋类
- 配饰
在我看来，我可以对上述 11 个类别进行硬编码，并让用户从针对每个类别量身定制的下拉框中进行选择。现在，我们以“Undershirt”和“Overshirt”为例。根据个人情况，可以选择长袖衬衫；他们还穿着一件。如果我让用户将值放入类别中，用户 A 可能会将其放入一个类别中，而用户 B 可能会将其放入另一个类别中。由于不同的类别，它们不会被比较。
现在，我可以将每个项目放入其自己的行中并按用户 ID 进行搜索，而不是在类别中进行硬编码（从而限制用户可以输入的数量）。但假设有一天一个人穿着短裤进入，然后穿着牛仔裤和衬衫。我如何确保它们是单独比较的（例如，连衣裙与短裤相比，连衣裙与牛仔裤+衬衫相比）而不是（连衣裙与短裤+牛仔裤+衬衫相比）。
至于实际比较，可以通过二维查找表来执行每个项目之间的比较。 （排式连衣裙与柱式牛仔裤的对比为 0，排式连衣裙与柱式牛仔裤的对比为 1）
I'm running into a conceptual problem that I cannot seem to conquer in my mind.
Let's say I want a user to enter what they're currently wearing into a database via a form. Throwing 'T-Shirt' and 'Blue' in a new row is incredibly easy. However, let's say I want to compare one users against others, and rank in order from most similar to least.
This becomes a huge nightmare when you consider the amount of options available.
- Undershirt
- Overshirt
- Jacket
- Scarf/Necklaces
- Headwear
- Pants
- Underwear
- Leggings
- Socks
- Footwear
- Accessories
As I see it, I could hard-code in the 11 categories above and let a user make selections from drop-drop boxes tailored to each category. Now, let's use an example of 'Undershirt' and 'Overshirt'. Depending on the person, a long-sleeved shirt could be used as either; they're still wearing one. If I make users put values in categories, User A might put it in one and User B might but it in another category. And they wouldn't get compared because of that, separate categories.
Now, instead of hard-coding in categories (and thus making a limit of how much a user can enter), I could put each item into its own row and search by User ID. But let's say a person enters in shorts one day, and next throws in jeans and a shirt. How can I make sure that they're compared separately (e.g., dress compared to shorts, dress compared to jeans+shirt) and not (dress compared to shorts+jeans+shirt).
As to actually comparing, each item vs. each other could be performed via a 2d lookup table. (Row Dress vs. Column Jeans would net a zero, Row Dress vs. Column Dress would net a one)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
适当的设计取决于可接受的误差范围。如果可接受的错误为零，则您必须向用户提供类别，并让他们为每个类别指定真/假是/否，或从一组有限的可能答案中进行选择。
等等等等令人恶心。
或者，如果误差范围非常大，您可以允许简单的自由格式文本输入和单词匹配/部分匹配。错误稍微少一些：您可以设置同义词表并匹配所提供单词的同义词。
The appropriate design for this would depend on the acceptable margin of error. If there is zero acceptable error, then you must present the users with the categories and they specify true/false yes/no for each one or select from a limited set of possible answers.
Et cetera et cetera ad nauseam.
Or if margin of error is very generous, you could allow simple freeform text-entry and match/partial-match on words. Slightly less error : you could set up a synonyms table and match on the synonyms of the supplied words.
作为一般规则，正确设计数据库并担心稍后的报告。如果这不仅仅是一个思维练习，你可能想说你实际上在比较什么，因为根据上面的内容，一个人很可能会说“燕尾服”或“晚礼服”，并让细节被推断出来，而在在其他一些地区，这可能是不可能的。即便如此，似乎每个项目至少需要三列（字段）：
如果准确性特别重要，您将需要一位训练有素的面试官:)
我刚刚注意到该列表中的内衣，这甚至更复杂，因为，对于某个年龄的女士来说，完全的内衣与十岁的绅士来说，是完全不同的。
As a general rule, get the database design right and worry about reporting later. If this is not just a thought exercise, you may like to say what you are actually comparing, because with the above, a person is quite likely to say "tuxedo" or "evening dress", and let the details be inferred, whereas in some other area, this may not be possible. Even so, it seems that you would need a minimum of three columns (fields) for each item:
If accuracy is particularly important, you will need a trained interviewer :)
I have just noticed underwear in that list, which is even more complicated, because what would qualify as full underwear for a lady of a certain age is by no means the same as that for a gentleman of ten years.