我原来用Delphi做数据库,现在改用VC++6 && SQL 了,感觉很好,没什么麻烦的,比Delphi好多了,大家快改用VC做数据库吧?

Question

我用DELPHI：
  1。 DELPHI 构建的物件思路很清晰，互动性（在我看来）很好。
  2。 VC 对MFC的处理容易把编码员引入底层的系统关联，对于应用层（如我等的工作）来说有些舍本逐末。  （个人意见，仅做参考。） 

Answer 1

我完全不同意上层仁兄的意见
1.在对数据库处理方面,VB,VC,PB,还有D,没什么区别,不外乎读写数据.
2.VC能给程序员最大限度的灵活性,让你想怎么写就怎么写,而其它的工具封装的太多,让你搞不清南北,灵活才是我需要的.

Answer 2

请问：
  何谓OOP？
  我提一个小模型，请大家拿出方案：
    一个CUSTOMER，ORDER，要求1-MANY，系统的可维护，可扩展性 。
 
 
  几分钟后我将给出方案，还请各位认真考虑考虑。

Answer 3

在关于领域模型的分析，建构，分割中，是不可能去考虑操作系统级的问题的，依据我们所对应的
系统领域，能够写出正确的系统已经很困难的了。各种编程工具，JAVA，C++，DELPHI 提供了达到OO实作的性能，但没有哪一种提供OO！！！
我用C++写算法，C++鼓励写类（不管高手低手），灵活性首居一指。不过好象JAVA的无指针很受欢迎，为甚麽呢？

Answer 4

laozi gangcai zai vc nali tingshuo "yong delhpi kaifa shujvku genghao"cai lai zheli de,xiang bu dao you yao wo huiqu.wo kao.

Answer 5

不求进步的家伙！！！
自以为在FORM 上加加控件设设属性即为程式设计，那算哪门子程式？这是甚麽设计？COPY别人的东西熟悉使用方法，然后听着对计算机一知半解的同学的赞叹“高手啊！”？？？……，我恨！

Answer 6

楼上的,你听着,
ＯＯＰ是你的追求吗?
ＯＯＰ的第三个特性就是可重用性,
我们copy ,在代码级重用,
这些你不会不了解吧,
copy不丢人,
那种只追求底层,而不尊重,不吸收别人的成果的人,
至少是一个不明智的人,
我们用ＤＥＬＰＨＩ才是真正的了解了OOP

Answer 7

再说一句，rad工具中的控件在异常保护方面考虑得很周全，你这位“高手”要是把所有可能出现的异常都自己从底层编码进行处理，可能一个很小的应用都要花比别人多出10倍时间。况且你不可能比borland的人考虑的更周全。

Answer 8

向大家介绍一本VC关于数据库方面的经典之作---->《Visual c++ 6.0 数据库开发指南》
李博轩 编著  清华大学出版社。现在杭州庆春路购书中心热卖中。

Answer 9

百花齐放,百家争鸣
用什么都行,只要按时,符合要求的完成程序就行啦,管它是B,C,D还是J

Answer 10

拜托贴到vc论坛去好吗，这里是delphi论坛

Answer 11

数据库开发首要的是开发速度和稳定性，Delphi可以了

Answer 12

呵呵！今天甚麽都没做，无聊之极来上网，没想到变成目标了。
事先声明，我乃菜鸟一只，dhl2001(一块红布)　3nt(3nt)：再说一句，rad工具中的控件在异常保护方面考虑得很周全，你这位“高手”要是把所有可能出现的异常都自己从底层编码进行处理，可能一个很小的应用都要花比别人多出10倍时间。况且你不可能比borland的人考虑的更周全。 冒昧兄弟进言： 我所提的系统各位有教好的解决方案了吗？ 分几层？ 各层责任如何？如果各位有疑惑的话，算我白说，建议到 www.simling.com 看看再说。好了，谁还有意见尽管提，不过请先想想 REUSE 的真正意含！

Answer 13

to intitora
你说得网站我进不去，依我得理解，一般说来要分三层，一个是数据层，一个database对象就够了，另外一个是业务层，这里包含customer,order对象，用来产生具体的customer和order对象，这是第三层，可能我说得不太清楚，其实我自己也搞不太清楚，只是看了一本书，硬般过来得，呵呵

Answer 14

GOOD！非常棒，能有你这种见解的实样少之又少！本来想实作出来，比较麻烦。第三层 --暂且叫--连接层吧，你做做，看行不行。应该说比较麻烦，特别是后面的封装。有甚麽主意麽？

Answer 15

超级小系统当然两张TABLE了，DATA AWARE！ 哼……要是模型不能解决N层，设计它有何用？你做过这种系统麽，比较一下。呵呵。

Answer 16

aggie(老邬):对不住之至： UML小组 应是： www.smiling.com.cn

Answer 17

没人抬杠麽？ 200张表？200 个INSTANCE 呗！ 3-8 个关联？ 太少了？ 仅仅几个PROPERTY 就如此紧张？

Answer 18

没人抬杠麽？ 200张表？200 个INSTANCE 呗！ 3-8 个关联？ 太少了？ 仅仅几个PROPERTY 就如此紧张？我要走了，一月不上网，没钱了，可怜啊！

Answer 19

老兄的可扩充性和可扩展性有没有个标准先？关键是需求分析，象你这样去做做得再好，也就是个小磨坊。没有哪个系统的可扩充性和可扩展性能够完全满足用户的全部需求。今天没有，明天就会给你提的。200张表就了不起了吗？关键是通过需求分析确认业务逻辑。50张表的系统也可能比你200张表的系统复杂的多。语言只是语言，是我们与计算机交流的工具，只要能说的明白，用什么都可以。VC用Ado连接数据库有些声明要加上，除此之外，和大多数语言都是一样的。计算机行业，流行的都是好东西。因为流行的代表效率被某一类人认可，这个行业是完全利益驱动行业。

Answer 20

我认为clp_1234是再卖弄自己的水平，我可以用pb三天内做一个财务系统，你用vc咱们比比看先？   做什么样的事情用什么样的工具，近距离作战你非要用大炮，你不找死才怪！

Answer 21

用VC做数据库开发？
我也会用到VC，但是不是数据库开发。
我一般用Delphi和C++Builder做数据库开发，有时也会用VB（不是我自愿的）.建议去看医生！

Answer 22

用VC作数据库开发? 你是用esql或者oci吗? 如果不是, 我感觉不到任何优势.

Answer 23

你的数据访问采用ADO还是其他方式。
我觉得在VC中访问数据库不如Delphi的方便！
希望你能给点提示！

Answer 24

我测试过，odbc的速度绝对没有BDE快，方便就更不用说了

Answer 25

我靠，不要误导好不好呀！！我刚用VC搞了一次数据库，又累又慢！搞数据库的东东还得用delphi，vb....的说

Answer 26

    写软件不是简单的“写代码”，重要的是实现用户需求而且要考虑开发成本（效率、测试、熟练人员数量等），特别是数据库应用系统的开发，前期的分析，系统结构（根据并发用户量、网络构成、操作人员水平等考虑C/S、B/S、多层结构及如何分布等）、表结构、关系设计、安全性、并发性、事物完整性考虑...
    用DELPHI没什么不好，你如果那么有空、投资够、认为写代码比做设计有意思的话用VC也可，语言只是实现你的想法的工具，如果你的想法在Form上放几个组件设点属性就可的话你又何必为一样样的功能哼哧哼哧写它几百上千行代码呢？有必要吗？如果真那么喜欢打字那干脆做打字员去！软件公司可养不起程序员收入水平的打字员！退一万万步，就这样你也没必要去骂让你效率更高、更具创造性的可视开发工具，如Dlphi你一样可以完全用API的方式去Create Window去往上面加Edit...构造自己的消息循环...
    我们现在开发的这个系统用的就是Delphi + Oracle + Corba，实现包括GIS+OA+MIS的功能，涉及到上千个表（而且也用可视化工具ERWIN进行表的管理）、GB级的测试数据量（光GIS数据就有几个G）不管在数据访问效率、图形处理效率上都很令人满意...以前也做过PB+SYBase(学校内部管理系统）、VB+SQLServer（C/S企业管理系统）、VB+ASP+VC+SQLServer（B/S结构)的几个应用。从来没有用户因为我们用可视化开发工具而对我们做的软件不满意、或少付钱的情况~
    最后请问clp_1234，你对Delphi了解多少？我用VC也有段时间，但从来不认为它比Delphi灵活。OO的思想就是封装,你所说的"而其它的工具封装的太多,让你搞不清南北"难道MFC不是？重要的是实现，用Delphi写的Foxmail大家都熟悉吧，难道比其它用VC写的EMail Client差？？？你理不理解什么是灵活？人家DELPHI整个VCL代码都是公开给你的，没有认真去看看它的实现、封装就不要在这里谈Delphi！
    最后，给初学者提个建议，“用效率高、先进、流行的工具实现你的想法”，不要让一知半解的人误导你！语言本身没有任何“高级”可言。

Answer 27

我想clp_1234肯定刚刚开始用VC，我想问一下，用VC怎样处理那成百上千个表的输入、输出以及显示。
   我对VC很熟，但我重不用VC做这些事，除非是逼不得已。

Answer 28

用VC怎样处理那成百上千个表的输入、输出以及显示?通过ADO调用SQL不行吗?

Answer 29

我来了!
piaoling跟lwg7603都说不无错,
Delphi是给了我们很多垃圾，但做起数据库，都是一些中大型的程序吧，也不会去计较了，
但如果说要写一些非常小巧的程序，Delphi就是非常耐心地自己一字一句写，这跟VC无多少分别，但也可写出VC的小与快!
我做数据库也首选Delphi+SQL,因为性能与VC差不多，但界面与用户的控制，VC根本无法在花费相同的人力物力做得比Delphi好.

Answer 30

to initora(initora)
你经常去 umlchina吗？
居然不知道3nt，哎，看来我正是老了。||8-）.
系统建模和工具没多大关系。在wintel平台上做三层结构目前还是用delphi开发最好。详情请参考李维的几本书。

Answer 31

to panjy 你的名字和think一样，是同一个人吗？
用VC怎样处理那成百上千个表的输入、输出以及显示?通过ADO调用SQL不行吗? 
在业务逻辑层当然没问题，但是在表示层，或者说界面方面用vc相当的麻烦。

Answer 32

又,最近有一本好书出版《uml 面向对象设计基础》邮电出版。原名是：Fundamentals of Object-Oriented Design in UML，翻译成"ml 面向对象设计基础"和原意有所不符。本书主要不是讲uml，而是以uml作为描述工具讲面向对象设计策略的。经典之经典。