您当前的位置:
请教一个数据建模的问题
我只是在概念上知道数据建模是开发中的一个环节，但是我对这个环节的实际作用仅限于建立数据库的程度。
现在假设讨论的数据库都是面对大型应用的，那么数据建模在多大的程度上对程序的性能和设计产生影响？
我的意思是好的数据建模对数据库和程序有什么好处，不好的数据建模对数据库和程序有什么坏处？
另外是，如果对数据库A有一个很好的数据建模，那么这个模型是否适合另一个数据库B？也就是说要有多大
的修改才能适合另一个数据库？
希望能举例讨论一下，分不是问题，我可以另外开贴给，只要说得好要多少给多少
------解决方案--------------------
我觉得你可能把数据建模和数据层设计给搞混了。
从你后面描述来看，你应该是想知道系统设计中的数据层设计，或更具体一点讲是数据库设计。
现在业界讲的“数据建模”是指用数据仓库理论，对现实中多数据库（称为数据仓库，或数据集市）进行建模，以进行数据挖掘的工作。
如果是指数据库设计，则是指一个数据库，规模大小是另一回事，当然规模太小的话就看不出很多设计问题，甚至你不加任何索引，性能都不会有太大影响，所以优秀的设计肯定是指一定规模以上才有意义
------解决方案--------------------
如果把数据建模改称数据库设计会更贴切主题一点。不好的数据库设计会很大程度的影响数据的效率，对于以后的系统扩展也会有很大的影响。
数据库设计根据不同的业务需求会不同，一个业务系统A的数据库设计会和另一个系统B的数据库设计一点也不一样！
------解决方案--------------------
不好的数据模型，小一点的说，会带来更多的不良代码；大一点就会影响系统性能。这个好理解的。数据建模的好坏，个人觉得，主要是对你的研究对象的理解的程度；一个一个实体，清楚了；他们之间的关系清楚了；然后用最简单的说法，把它描述出来。同一个对象可以有很多中描述，可以建出很多种模型；在实践中，你会慢慢知道的；要举例子，这一会很难说清楚的。
像学打牌，先打哪个，后打哪个，你知道了；然后在不断的打牌中，你会知道先打哪个更好些，再打哪个最好。那种组合最好，每次都是不一样的，因为别人的牌总是会有一些变化；虽然变化不大。
------解决方案--------------------
模型是个抽象的概念。数据库设计也可以算是存储模型的一种。
设计中主要考虑：
易用性：如果让用户方便使用数据模型
可维护性：如果进行数据库升级，日常维护是否方便
扩展性：是否可以方便的升级，修改以适应可能的变化
效率：如何让设计可以更快的运行
...
考虑点太多了，具体的侧重跟实际需求有关。
对于在业务处理过程中直接操作数据库的程序来说，数据库设计可以说就是整个模型设计。但实际上可能存在内存模型，程序操作内存模型，通过持久机制实现内存模型与数据库模型的同步。这种设计可能有些差异，比如“易用性”，“效率”等就侧重于由内存模型提供...
==>
另外是，如果对数据库A有一个很好的数据建模，那么这个模型是否适合另一个数据库B？也就是说要有多大的修改才能适合另一个数据库？
这个得看A的设计是否考虑到面向B的扩展性，如果设计得好，可能通过简单修改就能适用于B。也可能根据不搭边，得实是求是的分析了。