blocks|key|936011|text|是的，我会说这真的很糟糕。这是一个合理的选择，但这并不意味着它是正确的或好的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|936012|它破坏了第一范式。|936013|第二个批评是，将原始输入结果直接放到数据库中，根本不需要任何验证或绑定，这会使您面临SQL注入攻击。|936014|您所说的懒惰和缺乏SQL知识是新手所拥有的东西。我建议花点时间好好做，并把它看作是一个学习的机会。|936015|或者让它保持原样，吸取SQL注入攻击的惨痛教训。|936016|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Yes, I would say that it really is that bad. It's a defensible choice, but that doesn't make it correct or good.

It breaks first normal form.

A second criticism is that putting raw input results directly into a database, without any validation or binding at all, leaves you open to SQL injection attacks.

What you're calling laziness and lack of SQL knowledge is the stuff that neophytes are made of. I'd recommend taking the time to do it properly and view it as an opportunity to learn.

Or leave it as it is and learn the painful lesson of a SQL injection attack.

blocks|key|1150441|text|我在SQL+Server中的NTEXT列中使用键/值对制表符分隔列表已有4年多的时间了，而且它很有效。您确实失去了进行查询的灵活性，但另一方面，如果您有一个持久化/反持久化键值对的库，那么这并不是一个坏主意。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1150442|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Well I've been using a key/value pair tab separated list in a NTEXT column in SQL Server for more than 4 years now and it works. You do lose the flexibility of making queries but on the other hand, if you have a library that persists/derpersists the key value pair then it's not a that bad idea.

blocks|key|936110|text|一般来说，只要满足你的项目需求，任何东西都是可以防御的。这并不意味着人们会同意或想要为你的决定辩护……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|936111|一般来说，以这种方式存储数据不是最优的(例如，更难进行有效的查询)，如果您修改表单中的项，可能会导致维护问题。也许你可以找到一个中间的方法，用一个整数来表示一组位标志？|936112|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

In general anything can be defensible if it meets the requirements of your project. This doesn't mean that people will agree with or want to defend your decision...

In general, storing data in this way is suboptimal (e.g. harder to do efficient queries) and may cause maintenance issues if you modify the items in your form. Perhaps you could have found a middle ground and used an integer representing a set of bit flags instead?

blocks|key|1150527|text|“一个原因是懒惰”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1150528|这敲响了警钟。你应该这样做的唯一原因是你知道如何以“正确的方式”去做，但你已经得出结论，有一个明确的理由不应该这样做。|1150529|话虽如此:如果您选择以这种方式存储的数据是您永远不需要查询的数据，那么可能存在以您选择的方式存储它的情况。|1150530|(一些用户会对我在上一段中的声明提出异议，他们说“你永远不知道将来会添加什么需求”。这些用户不是被误导了，就是信奉宗教。有时，按照摆在您面前的需求工作是有利的。)|1150531|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

"One reason was laziness".

This rings alarm bells. The only reason you should do something like this is that you know how to do it "the right way" but you have come to the conclusion that there is a tangible reason not to do it that way.

Having said this: if the data you are choosing to store this way is data that you will never need to query by, then there may be a case for storing it in the way you have chosen.

(Some users would dispute the statement in my previous paragraph, saying that "you can never know what requirements will be added in the future". These users are either misguided or stating a religious conviction. Sometimes it is advantageous to work to the requirements you have before you.)

blocks|key|936221|text|如果您有固定数量的布尔值字段，则可以为每个字段使用INT(1)+NOT+NULL+(如果存在，则使用BIT+NOT+NULL+)或CHAR+(0)+(可为空)。您也可以使用SET+(我忘记了确切的语法)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|936222|entityMap^0|P|F|1E|C|1T|8|2E|3|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|G|$]]

If you have a fixed number of boolean fields, you could use a <code>INT(1) NOT NULL</code> (or <code>BIT NOT NULL</code> if it exists) or <code>CHAR (0)</code> (nullable) for each. You could also use a <code>SET</code> (I forget the exact syntax).

Imagine a web form with a set of check boxes (any or all of them can be selected). I chose to save them in a comma separated list of values stored in one column of the database table.

Now, I know that the correct solution would be to create a second table and properly normalize the database. It was quicker to implement the easy solution, and I wanted to have a proof-of-concept of that application quickly and without having to spend too much time on it.

I thought the saved time and simpler code was worth it in my situation, is this a defensible design choice, or should I have normalized it from the start?

Some more context, this is a small internal application that essentially replaces an Excel file that was stored on a shared folder. I'm also asking because I'm thinking about cleaning up the program and make it more maintainable. There are some things in there I'm not entirely happy with, one of them is the topic of this question.

Is storing a delimited list in a database column really that bad?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

设想一个web表单有一组复选框(可以选择全部或任意复选框)。我选择将它们保存在以逗号分隔的值列表中，这些值存储在数据库表的一列中。现在，我知道正确的解决方案应该是创建第二个表并适当地规范化数据库。实现简单的解决方案会更快，我想要快速地对该应用程序进行概念验证，而不必在上面花费太多时间。我认为在我的情况下，节省的时间和更...

问在数据库列中存储带分隔符的列表真的那么糟糕吗？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在数据库列中存储带分隔符的列表真的那么糟糕吗？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在数据库列中存储带分隔符的列表真的那么糟糕吗？
EN