110,537
社区成员
发帖
与我相关
我的任务
分享新手问个问题？什么时候用数据库，什么时候不用数据库
现在做了一个项目。一开始做的时候 就没想到用数据库，觉得直接用文本文件简单，所以也没去想，现在快做完了，忽然对什么时候用数据库，什么时候不用，这个问题不解了。希望大家多多指导。
1.什么时候用数据库？ 现在做的一个项目是C# WinForm,是直接从串口接收数据，然后存起来，数据内容是一个一个的数值，分20组，同时像股票曲线图一样实时显示出来。存下来的记录，之后也要用软件读取它把读取出来显示到图表中，因为当初想到直接读取文本文件很简单，所以就直接按照自己的规则，把数据存到了文本文件中。后来发现这个随着程序的运行。运行不间断时间达到1天的时候，收到的数据总共达到200MB左右，每个文件大概10MB，读取10MB的文件，然后显示到图表中，占用内存相当的多，自己也没处理后这个问题，后来人家问我为啥没用数据库。我纳闷了，不知道为何，当初就是觉得用文本文件简单么。对什么时候用数据库，什么时候不用非常不解，希望大家多多指导。这关系到一个软件的设计，我想搞清除它
1.什么时候用数据库？ 现在做的一个项目是C# WinForm,是直接从串口接收数据，然后存起来，数据内容是一个一个的数值，分20组，同时像股票曲线图一样实时显示出来。存下来的记录，之后也要用软件读取它把读取出来显示到图表中，因为当初想到直接读取文本文件很简单，所以就直接按照自己的规则，把数据存到了文本文件中。后来发现这个随着程序的运行。运行不间断时间达到1天的时候，收到的数据总共达到200MB左右，每个文件大概10MB，读取10MB的文件，然后显示到图表中，占用内存相当的多，自己也没处理后这个问题，后来人家问我为啥没用数据库。我纳闷了，不知道为何，当初就是觉得用文本文件简单么。对什么时候用数据库，什么时候不用非常不解，希望大家多多指导。这关系到一个软件的设计，我想搞清除它
...全文
请发表友善的回复…
发表回复
zhangshuqiang123 2010-12-06
- 打赏
- 举报
[Quote=引用 4 楼 wuyazhe 的回复:]
不用数据库，可以二进制序列化，存取速度快，出错比较麻烦，文本就是生成后修改容易，弄个记事本的打开即可。
[/Quote]不用关注数据怎么存，存成什么，但是当然是什么方法越简单越好
不用数据库，可以二进制序列化，存取速度快，出错比较麻烦，文本就是生成后修改容易，弄个记事本的打开即可。
[/Quote]不用关注数据怎么存，存成什么，但是当然是什么方法越简单越好
zhangshuqiang123 2010-12-06
- 打赏
- 举报
[Quote=引用 1 楼 gomoku 的回复:]
你的情况还是不需要数据库。
存成文本文件则不是好选择。
"一个一个的数值"直接存二进制数据不就可以了？
[/Quote]、
存成2进制？这样的话是不是要两次转换？
现在我的文本文件中存的都是
24,8,14,-3,27,19,11,11,11,22,10,18,0,-3,7,14,8,26,12,17,28,20,15,-1,3,7,12,-4,11,3,18,25,26,5,13,-2,-2,16,8,-2,
这样一行一行的数据。。
你的情况还是不需要数据库。
存成文本文件则不是好选择。
"一个一个的数值"直接存二进制数据不就可以了？
[/Quote]、
存成2进制？这样的话是不是要两次转换？
现在我的文本文件中存的都是
24,8,14,-3,27,19,11,11,11,22,10,18,0,-3,7,14,8,26,12,17,28,20,15,-1,3,7,12,-4,11,3,18,25,26,5,13,-2,-2,16,8,-2,
这样一行一行的数据。。
threenewbee 2010-12-06
- 打赏
- 举报
首先，使用文本文件比使用数据库简单只是一种错觉。你对这两者的掌握程度不一致。
就像很多人还说用电脑多麻烦，用纸、笔去算多简单一样。
数据库适合做复杂的，关系型的数据查询。不用数据库有很多情况，但是在这里不能展开讨论，因为你还不能理解那些。就你的这样的程序，其实简单到无论用数据库还是不用数据库，都非常简单的程度。
适合你的回答是，用数据库可以让你学习和体会下，数据库访问是什么，而且比你想象的简单。不用数据库的好处是，文本文件直接可以被人理解，适合数据直接被人Handle。
就像很多人还说用电脑多麻烦，用纸、笔去算多简单一样。
数据库适合做复杂的，关系型的数据查询。不用数据库有很多情况，但是在这里不能展开讨论，因为你还不能理解那些。就你的这样的程序，其实简单到无论用数据库还是不用数据库，都非常简单的程度。
适合你的回答是，用数据库可以让你学习和体会下，数据库访问是什么，而且比你想象的简单。不用数据库的好处是，文本文件直接可以被人理解，适合数据直接被人Handle。
vrhero 2010-12-06
- 打赏
- 举报
[Quote=引用 1 楼 gomoku 的回复:]
你的情况还是不需要数据库。
存成文本文件则不是好选择。
"一个一个的数值"直接存二进制数据不就可以了？
[/Quote]
对...如果全是数值，存二进制文件大小少说也会减小10倍以上...
你的情况还是不需要数据库。
存成文本文件则不是好选择。
"一个一个的数值"直接存二进制数据不就可以了？
[/Quote]
对...如果全是数值，存二进制文件大小少说也会减小10倍以上...
兔子-顾问 2010-12-06
- 打赏
- 举报
不用数据库，可以二进制序列化，存取速度快，出错比较麻烦，文本就是生成后修改容易，弄个记事本的打开即可。
anbin0814 2010-12-06
- 打赏
- 举报
[Quote=引用 2 楼 vrhero 的回复:]
先去学学何为数据库，看看数据库的发展历史...弄明白为什么要有数据库你就明白什么时候应该用什么时候不用了...
http://baike.baidu.com/view/1088.htm
[/Quote]
+1
先去学学何为数据库，看看数据库的发展历史...弄明白为什么要有数据库你就明白什么时候应该用什么时候不用了...
http://baike.baidu.com/view/1088.htm
[/Quote]
+1
vrhero 2010-12-06
- 打赏
- 举报
先去学学何为数据库，看看数据库的发展历史...弄明白为什么要有数据库你就明白什么时候应该用什么时候不用了...
http://baike.baidu.com/view/1088.htm
http://baike.baidu.com/view/1088.htm
gomoku 2010-12-06
- 打赏
- 举报
你的情况还是不需要数据库。
存成文本文件则不是好选择。
"一个一个的数值"直接存二进制数据不就可以了？
存成文本文件则不是好选择。
"一个一个的数值"直接存二进制数据不就可以了？
flyerwing 2010-12-06
- 打赏
- 举报
[Quote=引用 2 楼 vrhero 的回复:]
先去学学何为数据库，看看数据库的发展历史...弄明白为什么要有数据库你就明白什么时候应该用什么时候不用了...
http://baike.baidu.com/view/1088.htm
[/Quote]
很好很详细.
先去学学何为数据库，看看数据库的发展历史...弄明白为什么要有数据库你就明白什么时候应该用什么时候不用了...
http://baike.baidu.com/view/1088.htm
[/Quote]
很好很详细.
全栈深入 2010-12-06
- 打赏
- 举报
[Quote=引用 11 楼 sp1234 的回复:]
引用楼主 zhangshuqiang123 的回复:
当初就是觉得用文本文件简单么。对什么时候用数据库，什么时候不用非常不解，希望大家多多指导。这关系到一个软件的设计，我想搞清除它
你搞清了吗？
实际上这是一个组织工程问题，是动态的、用工程师的脑袋来适配、升级和不断测试的，而不是静态的在书上给你规定了2>1这种僵化的东西。
[/Quote]
sp1234每次回答都很高深莫测
引用楼主 zhangshuqiang123 的回复:
当初就是觉得用文本文件简单么。对什么时候用数据库，什么时候不用非常不解，希望大家多多指导。这关系到一个软件的设计，我想搞清除它
你搞清了吗？
实际上这是一个组织工程问题，是动态的、用工程师的脑袋来适配、升级和不断测试的，而不是静态的在书上给你规定了2>1这种僵化的东西。
[/Quote]
sp1234每次回答都很高深莫测
以专业开发人员为伍 2010-12-06
- 打赏
- 举报
[Quote=引用楼主 zhangshuqiang123 的回复:]
当初就是觉得用文本文件简单么。对什么时候用数据库，什么时候不用非常不解，希望大家多多指导。这关系到一个软件的设计，我想搞清除它
[/Quote]
你搞清了吗？
实际上这是一个组织工程问题，是动态的、用工程师的脑袋来适配、升级和不断测试的，而不是静态的在书上给你规定了2>1这种僵化的东西。
当初就是觉得用文本文件简单么。对什么时候用数据库，什么时候不用非常不解，希望大家多多指导。这关系到一个软件的设计，我想搞清除它
[/Quote]
你搞清了吗？
实际上这是一个组织工程问题，是动态的、用工程师的脑袋来适配、升级和不断测试的，而不是静态的在书上给你规定了2>1这种僵化的东西。
以专业开发人员为伍 2010-12-06
- 打赏
- 举报
总有人说：“要是一次就完美地决定了产品的架构岂不最高效？”
可是实践恰好想反，每当1、2月进行一次系统某个关键架构组件的重构，分阶段地做事往往比一次性地做事要可靠得多。那种期望找一个高手写一堆文档、然后把高手调开、而招聘几个会一点编程的低级程序员就能按图索骥开发好系统的小公司不懂，这种软件开发方法反而更慢。最快的软件开发方法就是懂得在摸着石头过河的过程中预先有计划地进行阶段性扩展。
可是实践恰好想反，每当1、2月进行一次系统某个关键架构组件的重构，分阶段地做事往往比一次性地做事要可靠得多。那种期望找一个高手写一堆文档、然后把高手调开、而招聘几个会一点编程的低级程序员就能按图索骥开发好系统的小公司不懂，这种软件开发方法反而更慢。最快的软件开发方法就是懂得在摸着石头过河的过程中预先有计划地进行阶段性扩展。
以专业开发人员为伍 2010-12-06
- 打赏
- 举报
lz其实无意中完成了一个正确和高效的开发过程，而此时的纠结也不太需要太在意答案。
用最简单的分层思维，我们高效地开发一个使用的、交互界面丰富的应用程序，表现层不应该纠缠于数据持久化层，因此有了业务逻辑层用于隔离。有了业务逻辑层的定义，你就可以尽快地让表现层开发出来并进行测试，此时如果没有必要使用数据库时就不要使用数据库。
现在的问题是很正常地，因为你已经高效地开发出了系统，并且很好地运营了起来，说明前期的选择是正确的，不必怀疑。置于现在是否需要将数据重新移植到数据库中，这其实完全不应该影响到系统的表现层的任何代码，只不过是在底层一点代码重写（转向数据库）或者扩展（原来的数据文件也参与查询、新的新增数据才写入数据库）。如果你看到这是一个进步过程，就无需怀疑，自己去决定是否需要改造你的底层代码。
用最简单的分层思维，我们高效地开发一个使用的、交互界面丰富的应用程序，表现层不应该纠缠于数据持久化层，因此有了业务逻辑层用于隔离。有了业务逻辑层的定义，你就可以尽快地让表现层开发出来并进行测试，此时如果没有必要使用数据库时就不要使用数据库。
现在的问题是很正常地，因为你已经高效地开发出了系统，并且很好地运营了起来，说明前期的选择是正确的，不必怀疑。置于现在是否需要将数据重新移植到数据库中，这其实完全不应该影响到系统的表现层的任何代码，只不过是在底层一点代码重写（转向数据库）或者扩展（原来的数据文件也参与查询、新的新增数据才写入数据库）。如果你看到这是一个进步过程，就无需怀疑，自己去决定是否需要改造你的底层代码。
