书生李肆
本人还是自称为菜鸟好了，学了一点相关知识，谈不上指点，心得倒是马马虎虎，见笑
数据结构和算法设计是分不开的（大学课程里面这是整个的一门课）。对于软件初学者，这部分内容不是特别重要，因为很自然，新手总是喜欢用简单、好理解、易实现的方式去写代码；由于软件本身的架构简单，在空间和时间资源的消耗上也几乎可以忽略。比如只有几十个数据排序，那么单向链表＋简单插入排序足矣。
随着学习深入，数据结构与算法的重要作用也就逐渐明显起来，尤其对于大型复杂的软件体系结构。因为硬件的发展速度远比不上软件的膨胀速度，对于一些大型的软件，可供使用的空间资源和可以容忍的时间复杂度相当有限（在使用者的角度，他当然会希望一个软件产品占用空间小，功能全，速度快），这就需要良好的数据结构和有效的算法去支撑，用上面的例子，如果有几十万个甚至上亿个数据需要排序，若不小心考虑数据结构与算法的设计，运行的结果将不堪设想。
一楼所说的数据库是一个重要的应用方面，尤其对于当今海量的数据而言。一个好的设计，可能用一台机子几分钟计算出结果，而一个差的设计，可能多机协同工作算几小时甚至几天。
更明显的例子就是操作系统，其作用毋庸置疑，当然需要高效、节约，因为还要支撑其他软件的运行；设计过程中，对于一些可选的数据结构以及算法，就要仔细斟酌了。
再比如游戏，太显然的例子，低端配置跑高端产品，谁都希望
在个人的学习过程中，理解数据结构和算法设计很有助于深入理解软件系统，无论自己写，还是读别人的成果。
个人的愚见。更多的精髓，如果楼主感兴趣的化，就会在学习中慢慢体会了
我现在在学软件开发，你说数据结构很重要，那到底有多重要，可以跟我说详细些吗？
当一样东西很重要时，解释与描述它的重要性的东西是不可数的，只能说它很重要很重要。就好像问你有多爱一个人，若你真的很爱那个人，你是无法描述其爱的程度的，除非你爱的不深；而你爱的那个人也可能是数据结构，呵呵。
可以这么说吧，你学软件开发，没有学数据结构的话，此时你就像一台可以运算的计算机，却不懂得如何运算，该怎样运算才能解决问题。再联系具体点，像上面那位老兄说的，即使你掌握了所有计算机编程语言，如果你没有数据结构的思想，我可以断定你没有把各种计算机语言学好，你也用不好各种编程语言。也许你知道如何使用各种语言的函数库，知道照猫画老虎弄几个可以运行的程序出来。但当你面对工程问题时，你还是会像个无知的傻瓜一样不知所措。
数据结构是你学的所有编程语言的精神领袖，它指导着各种语言该怎么做，才能更好更有效率地达到目的。没有了精神领袖的编程，就如行尸走肉，也能走。
如果面试时，你说你是学软件开发的，没学过数据结构，只要面试官不是傻子，它都不会再瞟你多一眼。
它有多重要？重要到你没学它，你就别出去跟人说你是学软件开发的。
这是我回答另一问题时的说法：怎样学好数据结构和要学到什么程度？
说得绝对点，数据结构很大程度上为了统筹指导编程的，当然也可以帮你挖掘数据，解决一些很实际的问题。要到什么程度？那要看你的专业需求，如果是单单为了考试，你把老师跟你说的一些基本概念都弄懂了、能用个别编程语言最好是做几个小实现就足够了，但为了轻车熟路来驾驭编程，你就必须把课本翻它个四五遍，在脑海里烙上各种数据结构如链表，树，图等的思想模型，最核心的是你学到能体会到它能很好的统筹指导编程和帮你解决一些实际问题（非编程）的内涵时，到了这个层次你就算是学好了，即使你忘了具体的思想模型，但你知道数据结构这东西能帮你做什么，你要怎样用它，这时再去翻翻书就可以。至于与具体语言关联起来的实现思路，当你有了各种数据模型，再去设计具体语言编程的时候就自然而然的轻巧许多，不用像无头苍蝇一样代码乱糟糟，毫无方向，更不用说清晰的思路了。数据结构是对信息的处理技术，它主要涵盖将数据结构化，再针对结构化了的数据设计算法从而方便处理。个人理解。
数据结构在软件开发中真得很重要吗
可以说重要也可以说不重要。
不重要：大部分应用开发是不重要的。因为这类知识不会直接用到。数据结构和算法已经被类库包括了，这些类库实现的很好，只要会用即可，不需要了解数据结构。并且一般的开发以业务逻辑为主，涉及算法的不多。
重要：有的开发是一定少不了这类知识的，比如搜索，游戏，模式识别等。这些应用直接使用相关的知识，不会数据结构简直是寸步难行。
重要：算法和数据结构代表了编程的思想，好比内功一般，语言和技术好比招式。招式凌厉固然重要，但是要进军到大侠的级别，没有深厚的内力就纯属扯淡了。
所以重要不重要看你自己，如果你做的应用和算法无关，只想做个普通码农，不想进军到大侠级别，那就别看了。看了也是浪费时间。
数据结构和算法在实际的软件开发中都有哪些
应用太多了。
基本上来说C#是基于面向对象语言，你所定义的所有类/结构体都算是数据结构，而且在.net类库中已经定义中诸多可用的类型以供使用。实际开发中根本就离不开结构与算法。
题主之所以有这样的问题，基本上认识到了很多程序员易犯的一个毛病——理论知识与实际应用中的脱节问题，不少程序员都说自己写程序用不上理论知识，或者是理论无用。我一直认为理论才是真正编程的指导，别说你所学的理论知识了，有时我们必须遵守一些软件活动上的标准/规范/规定。比如ISO29500标准有多少程序员读过或听说过？他实事就是关于openxml的一个国际标准，我们要想达到通用的程序，这些标准还是读一读的好。
扯回你的问题，什么是数据结构，什么是算法？如果你真的狭义理由数据结构，或者只是从课本上例子来说，数据结构被定义成一个只有属性成员的类或结构体才算是数据结构吗？事实上并不是，那么是不是只有链表/栈/队列才算是数据结构呢？可以说这是某些人狭义理解数据结构时的一种常规定势思维，但事实上来说，类或结构是数据结构的基本，否则你链表存在的实体到底是什么东西？所以数据结构包含着基本结构与狭义上的顺序表/链表/栈/队等存在实体的集体。为什么我说数据结构在实际运用中广泛体现呢？就数据结构而言，课本上只是为了讲明白结构而已，弱化了其中实体的真正含义，而且不语言的具体实现亦不尽相同，所以他们所讲的数据结构是基本理论的。
我来个例子：链表（C#语言）
publicclassMember{
publicstringName{get;set;}
publicstringResponsibility{get;set;}
publicstringPosotion{get;set;}
}
publicclassMemberNode
{
publicMemberMember{get;set;}
publicMemberNext{get;set;}
}
//Node其他就是链表中的一个结点结构，这个结点结构除了指明当前的Member之下还指向下Next的下一个结构结构，它最终可以形成一个链表。这就是定义的一个链表。
从以上例子上你可以看出这是一个类似于课本的标准定义，但事实上在C#语法中存在泛型的特点，那么这类似的结构我们不须要一个个地定义了！所以在不同的语言中为了方便编程者，我们甚至可以把这样的结构进行简单化，从而达到一种最简单的使用方式。以C#为例，我们可以使用Node<T>来表示链表/List<T>表示顺序表/Stack<T>表示栈/Queue<T>表示队列，在这种情况下，我们只需要定义我们的泛型即可，结构链之类的本身使用泛型已经在类库中实现了——虽然你不用定义，但不代表不使用或者不用理解这其中的知识。而在课本讲理论的时候，他不可能附带泛型来讲的，所以很多人认为自己去定义数据结构才行，那才是“真正”的数据结构，其实不然。以链表为例，我们需要一个节点除了其实体意义之外，还存在指向下一结点的指针（其实是地址引用）才算是数据结构。根据课本，他们必须这么定义（C#）：
publicclassMemberNode{
publicstringName{get;set;}
publicstringResponsibility{get;set;}
publicstringPosition{get;set;}
publicMemberNodeNext{get;set;}
}
//死读书的只会承认这种才是真正的数据结构吧（链表节点）
事实上，链表讲的只是一种形式，能最终形成的一种组织数据结构的形式。这个代码会导致我们出现一种极大的误解——每个类型的结构都需要重新定义一次。如果有多个类型结构的话，我们会出现多个不同的定义，这会导致将来类的定义越来越多，对于维护上来说是比较麻烦的。由于设计模式/面向切片等各种开发方式的介入，我们会使用相对比较简单的形式。所以才会有我定义两个类的进步，而后可以出现泛型的更进一步。
你可以这样理解，这种课本上的结构，会导致我们造成每种结构基本上都需要重新定义一次，我最开始给出的例子可以使用继承的方式，实现某个基类的数据结构（下面的似乎也行，但在使用中可能会出现部分问题），而Node<T>则从根本上解决了这个问题，可以支撑多种类型。
所以此时在理解数据结构时，比如Node<T>，他不旦要求理解链表的节点，还要理解T泛型，那么在数据结构上来说，它指的不再是单一的节点结构，还在包括一个基础的类型。
换句话来说，你在C#等语言中已经不需要再做类似的定义了，只需要定义其基本结构类型即可。但课本上在讲知识的时候，它不可能只针对面向对象或支持泛型的语言来讲，若不支持泛型时，我们必须使用课本上或我最开始写的例子中的形式，若不支持继承的面向过程语言，那么课本上的知识就是硬性的规定，你必须以这种形式来说，而引用则使用指针引用的方式（面向对象的引用其实是一种引用型引用，也就是址引用或称地址引用，与指针类似）。
相信讲到这里你能明白，数据结构在不同的语言中只是变了个形而已，并不是必须是存在指针的才是，也不是只说表面上的那点东西。早期教程都是以fortain语言为主的，而且课本的目的是讲清道理，而不是一种规定。死读书的人以为用不到数据结构，其实他们一直在使用。
再来说一下算法，算法是什么？是解决问题的一种模式，比如解二元一次方程等等，所以算法的定义其实已经告诉你，顺序代码他也算是一种算法，不能说只有背包问题，八皇后问题，回溯问题才算是算法——你能明白吗？其实你正常写的就是一种算法，这种算法简单，就是顺序执行下来就可以了，他也是一种算法的，就算解二元一次方程组有固定的模式（算法），但不代表加减法就不是算法了！所以算法也是常用的东西，那么你学习的算法其实算是开辟思路的一种而已。算法自身的概念已经决定，基本上程序都是由结构与算法构成。我也来举个例子，怎么判断某个链表是否为循环链表？是你的回溯算法，贪心算法还是背包算法？它们只是在解决一些典型问题的一种通用方式而已，很显然，我的问题不是这种典型问题，但不代表他不典型，我们正常的算法是设计两个变量等于头元素，然后开始进入循环，一个变量每次向下推一，即找到他下一个节点，而另一个变量每次找到其孙节点，就算当于两个变量一个每次向下推进一次，而另一个每点推进两次（如果可能），如果不是循环链表，则进两次的那个会在链表总长度的一半时，遇到空引用，否则会在某一时间两指针引用同一对象（不是对象相等，而是引用相同的对象），什么意思呢，好象两个人在圆型跑道上跑步，一个每秒1米，另一个每秒2米，同时同地同向出发，最归跑得快的那个会追上跑得慢的那个！当然这种情况下你也可以给他起个名字，叫“追及算法”？如果只有你学的那几个典型算法是算法的话，这个算不算算法？
现在我们的问题是，如果语言层面上已经实现了这些东西，那么这些理论我们是否可以不用理解就可以了？答案是可以——如果你只是一个不思进取的程序员或允许bug乱飞的没有责任心的编程人员的话，可以不用理解——毕竟有些人只是“混”饭吃而已！
理解了不会去应用，这就是典型的理论联系不到实际，他们也不知道自己的代码将如何控制。我举一个例子，由于性能等各方面的要求，我们要使用多线程对某些数据进行处理。怎么处理？不好人会使用多线程——他们定义一个临界资源，然后让多个线程在读取数据表(DataSet)时进行阻塞，然后每个线程去处理那些超时长的问题，处理完的时个再按这种方式读取数据——这样有问题吗？没有，这也算是算法的一种！反正如果编程代码有功底的话没有任何问题的，这种代码算不算优雅呢——很多人认为代码的优雅就是代码编写过程的形式或是良好的编程习惯！这里边其实用不到数据结构与算法的。
好吧，我承认，但如果我们换一句思路来看看，如果我用一个线程负责读取数据，并不停地放入到一个队列中，而多个线程从队列中不停地读取处理这些放入的数据，这样如何？我的意思是说，并没有直接在DataSet中处理，而是选择使用队列的方式。
我们看一个问题，这个队列Queue<T>，一个线程用来插入数据，多个线程用来读取数据，而且要保证不能重复，那么我们可以使用队列的安全版本（CorrentQueue<T>,在.net中如果非线程安全的情况下，多线程使用实应该找到其对应的安全版本或者控制线程安全)。
插入线程如果发现队列中的长度（容量）较大时，可以暂缓插入。这样可以保证队列的长度基本固定，占用内存得到控制（不是DataSet批量读来一大堆），由于使用安全队列，所以各线程不用考虑线程之间的安全问题，每个线程从队中获得数据并删除，可以保证数据只被处理一次。当然还可以考虑优雅的通知机制，插入线程在插入数据时通知处理线程启动，如果插入速度过快，发现插入数量达指定的长度（比如30个），停止插入，插入线程阻塞；处理处理再次处理时可通知插入线程再进行插入。
这也算是一种算法吧？它可以让插入线程与处理线程同时工作，而使用DataSet那种常规的结果时，只能是等待处理完或加入多个控制条件进行控制，既然这么控制的话，何不直接使用队列的方式？CorrentQueue<T>中的T也完全可以是一条记录DataRow嘛！
如果你认为第一种是你经常使用方式，那么算法对于你来说学与不学无所谓的，你必须使用自己的编程/调试功底以保证你的代码尽量很少出错或不出错。而如果你认为第二种方案优雅一些的话，那么你会认为你学习的算法与结构还是有用的，理论与实践结合了。
我之所以举这么一个例子，其实告诉你的无非是几点非常重要的信息：
你有选择算法的自由（只不过是代码质量、后期维护的问题）
如果你知道的较多的算法与结构，你会有更多的选择。
算法或结构在实际使用中，所谓的典型问题并不是使用场景和书上描述一模一样（试想一下，我第二种考虑的例子中，是不是跟书上比他不典型？其实也是非常典型的）
分析问题时，应该拿要点，而不是整体去套。（如果整体去套用的话，你肯定会想不到使用哪种结构或算法）
不管是数据结构/算法/设计模式都要求是灵活运用，而不是场景对比使用，也不是生搬硬套。
试想一下，你的背包问题，怎么可能公司也让你分拆包装？你的八皇后问题公司恰好让你下棋？你的贪心算法公司恰好让你找零钱？你的回溯算法公司恰好让你走迷宫？学不能致用的原因就是太死板——这几个举个例子的场景你再遇到或理能遇到的机率是非常小的，所以如果觉得学了没用，那就真没用了——只不过不是算法没用，而是人没人！
讲个小故事：从前一个家人的板凳坏了，要找一个合适的两股叉的树杈重新制做一个板凳腿，让孩子到树园里找了半天，孩子回来说“我都没见过有向下叉的树杈！他老爹气得要死——怎么会可能有向下长的树杈呢！这孩子是不是笨——你就不会把地刨了找一个向下分叉的树根！
算法也是一样，迷宫找路可以使用回溯算法，但不是所有的回溯算法都用于迷宫找路——它还可以用来设计迷宫！嘿嘿嘿！
学软件开发需要学习什么知识？数据结构和算法与数学有关系吗？
软件开发需要学习一门汇编语言，算法等于是软件的原理，和数学有一定的关系。
你做软件的，首先要知道软件是什么原理来实现这个功能的，连自己都不知道原理，就不可能做出来了，比如，输入圆的半径，软件计算圆的直径，你要知道半径怎么算出直径。才能做出软件。
什么是面向数据结构的软件开发方法
在上个世纪60年代中期爆发了众所周知的软件危机。为了克服这一危机，在1968、1969年连续召开的两次著名的NATO会议上提出了软件工程这一术语，并在以后不断发展、完善。与此同时，软件研究人员也在不断探索新的软件开发方法。至今已形成了八类软件开发方法.
其中一类就是面向数据的软件开发方法：
面向数据结构的软件开发方法
1、Jackson方法
1975年，M．A．Jackson提出了一类至今仍广泛使用的软件开发方法。这一方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业应用中的文件表格处理。该方法也可与其它方法结合，用于模块的详细设计。
Jackson方法有时也称为面向数据结构的软件设计方法。
2 、Warnier方法
1974年，J．D．Warnier提出的软件开发方法与Jackson方法类似。差别有三点：一是它们使用的图形工具不同，分别使用Warnier图和Jackson图；另一个差别是使用的伪码不同；最主要的差别是在构造程序框架时，Warnier方法仅考虑输入数据结构，而Jackson方法不仅考虑输入数据结构，而且还考虑输出数据结构。
做安卓软件开发中哪一个方面对算法与数据结构要求高
如果有兴趣可以深入学习安卓的view系统，里面涉及到视图的测量和布局方案，还有绘图原理，矩阵变化，OpenGL接口，写出自定义的高效UI，如果觉得自己的算法能力超强，就去搞游戏吧，碰撞检测算法，AI算法，物理效果模拟.
转载请注明出处51数据库 » 软件开发中的数据结构 数据结构在软件开发中的作用
