g***t
发帖数: 2278 | 1 Zend vs. CakePhp vs. CI vs. Symphony
据说Symphony功能最强大，最适合大型网站。
但是啥是大型网站呢？到底大型网站的定义是什么？
还有另外一个问题，如果一个表格(table)的记录越来越多，多到非常庞大，那么应该
如何处理 |
l*****a
发帖数: 166 | 2 大型网站 一般指 功能多，信息量大，用户多，流量大，更新频率高，软件和数据多而
复杂，开发和维护人员众多，对reliability, security, speed, availability等有较
高要求。应该没有固定的定义。一般 e-commerce, intranet, e-government, portal,
mitbbs, etc.都算吧？
【在 g***t 的大作中提到】
: Zend vs. CakePhp vs. CI vs. Symphony
: 据说Symphony功能最强大，最适合大型网站。
: 但是啥是大型网站呢？到底大型网站的定义是什么？
: 还有另外一个问题，如果一个表格(table)的记录越来越多，多到非常庞大，那么应该
: 如何处理
|
l*****a
发帖数: 166 | 3 关于表格（是html table?），我想可以分页：可以分成 physical html files, or
parametered dynamic page, or use expand/collapse function.
just some random thoughts...
【在 g***t 的大作中提到】
: Zend vs. CakePhp vs. CI vs. Symphony
: 据说Symphony功能最强大，最适合大型网站。
: 但是啥是大型网站呢？到底大型网站的定义是什么？
: 还有另外一个问题，如果一个表格(table)的记录越来越多，多到非常庞大，那么应该
: 如何处理
|
s*******h
发帖数: 2148 | 4 我觉得他说得是数据库里的表格
【在 l*****a 的大作中提到】
: 关于表格（是html table?），我想可以分页：可以分成 physical html files, or
: parametered dynamic page, or use expand/collapse function.
: just some random thoughts...
|
g***t
发帖数: 2278 | 5 嗯
【在 s*******h 的大作中提到】
: 我觉得他说得是数据库里的表格
|
B*****g
发帖数: 34098 | 6 you need to ask on database board
【在 g***t 的大作中提到】
: 嗯
|
c***c
发帖数: 21374 | |
l*****a
发帖数: 166 | 8 多了就分拆，横向分拆。比如说交易记录，可以archive。这是简单的，复杂的的话要
考虑好多因素。问database版。
【在 g***t 的大作中提到】
: 嗯
|
r****y
发帖数: 26819 | 9 right
php is mainly good for a common forum site.
【在 c***c 的大作中提到】
: 大型网站就不应该用php :)
|
s****y
发帖数: 983 | 10 这话说得，php的大型应用也是很多的。
至于框架的选择，那就是广告里的一句话，直选对的，不选贵的。
每个框架都是有忧有劣，你觉得用得顺手就好了。
如果数据库繁重，可以试试php的orm相关的框架
【在 r****y 的大作中提到】
: right
: php is mainly good for a common forum site.
|
|
|
r****y
发帖数: 26819 | 11 很多要看跟什么比，和java比企业级别的大型应用，就不够多了。
php的长处不在于做大，而在于做小。
【在 s****y 的大作中提到】
: 这话说得，php的大型应用也是很多的。
: 至于框架的选择，那就是广告里的一句话，直选对的，不选贵的。
: 每个框架都是有忧有劣，你觉得用得顺手就好了。
: 如果数据库繁重，可以试试php的orm相关的框架
|
c***c
发帖数: 21374 | 12 php的特点是灵活
灵活的东西就不适宜做大的东西
就php来说，我觉得Symphony完全走了一个错误的方向
cakephp也走了些弯路。比如说cakephp支持php4，但是却把自己报装成一个很OO的东西
，而php4本身比不OO，因此cakephp绕了多大的圈子可想而知。而且动辄产生一个很复
杂的array of array of array.另外ORM也是完全没有那么大的必要，对于php应用来说
，很多时候直接写SQL更合适。 |
l*****a
发帖数: 166 | 13 恩 有道理。
不过 jsp, asp, .net, 等等啥的，虽然underlying framework very complex, 但是使
用上也很灵活阿。
【在 c***c 的大作中提到】
: php的特点是灵活
: 灵活的东西就不适宜做大的东西
: 就php来说，我觉得Symphony完全走了一个错误的方向
: cakephp也走了些弯路。比如说cakephp支持php4，但是却把自己报装成一个很OO的东西
: ，而php4本身比不OO，因此cakephp绕了多大的圈子可想而知。而且动辄产生一个很复
: 杂的array of array of array.另外ORM也是完全没有那么大的必要，对于php应用来说
: ，很多时候直接写SQL更合适。
|
o***g
发帖数: 2784 | 14 做网站的，需要关心的就是peak time traffic就好了。
所以大网站就是流量大。更准确地说是峰值的流量大。只要峰值的时候能撑得住就好了。
技术上说，就是从memory data到html到浏览器显示的过程是做网站的需要负责的。
业务逻辑复杂的，你需要找个业务逻辑专家来协助。
数据量大的，需要找个数据库专家来协助。
如果select * from sometable where name='xxx';在一个千万以上级别的表里面没有
加索引，用啥做也白扯。不是php或java或什么framework能够解决的。
如果数据量再大，需要分表的时候，程序方面也就需要参与了。
框架的唯一目的是快速开发，无他。缺点就是损失性能。
大型网站就是需要性能，两者是矛盾的。
所以大型网站不用框架。
大型网站想要提高性能就是在memory data到浏览器显示结束这段时间内所有的事情上
想办法加cache和加人手(cluster)。当然设计上不能有大问题。
当然还有，可以做一些预处理，在非峰值的时候预处理一些数据，放着，等峰值的时候
使用。在我看来思路是一样的。
大型网站，都大型了，专门为他开发也不 |
g***t
发帖数: 2278 | 15 俺打算用Yii做php的框架了，貌似是国人写的，而且很新。
俺现在犹豫的是要先把OOP和Pattern的概念彻底掌握了再学框架，还是直接用框架。
【在 c***c 的大作中提到】
: php的特点是灵活
: 灵活的东西就不适宜做大的东西
: 就php来说，我觉得Symphony完全走了一个错误的方向
: cakephp也走了些弯路。比如说cakephp支持php4，但是却把自己报装成一个很OO的东西
: ，而php4本身比不OO，因此cakephp绕了多大的圈子可想而知。而且动辄产生一个很复
: 杂的array of array of array.另外ORM也是完全没有那么大的必要，对于php应用来说
: ，很多时候直接写SQL更合适。
|
g***t
发帖数: 2278 | 16 您的意思是大型网站就是做自己的框架，比较不会有多余的东西？
还有，API和框架的区别是什么
了。
【在 o***g 的大作中提到】
: 做网站的，需要关心的就是peak time traffic就好了。
: 所以大网站就是流量大。更准确地说是峰值的流量大。只要峰值的时候能撑得住就好了。
: 技术上说，就是从memory data到html到浏览器显示的过程是做网站的需要负责的。
: 业务逻辑复杂的，你需要找个业务逻辑专家来协助。
: 数据量大的，需要找个数据库专家来协助。
: 如果select * from sometable where name='xxx';在一个千万以上级别的表里面没有
: 加索引，用啥做也白扯。不是php或java或什么framework能够解决的。
: 如果数据量再大，需要分表的时候，程序方面也就需要参与了。
: 框架的唯一目的是快速开发，无他。缺点就是损失性能。
: 大型网站就是需要性能，两者是矛盾的。
|
k********e
发帖数: 702 | 17 数据库表大了可以用partitioned table。还可以cluster。很多办法。 |
B*****g
发帖数: 34098 | 18 大家的网站都这么大？
【在 k********e 的大作中提到】
: 数据库表大了可以用partitioned table。还可以cluster。很多办法。
|
l*****a
发帖数: 166 | 19 框架就像 汽车的底盘，API就是pedal,油箱口，方向盘，仪表等。
【在 g***t 的大作中提到】
: 您的意思是大型网站就是做自己的框架，比较不会有多余的东西？
: 还有，API和框架的区别是什么
:
: 了。
|
k**o
发帖数: 15334 | 20 庞大是多大？mysql一个表几百万条数据，只要有index，应该还是没问题。如果再多，
也很简单，理顺一下数据，然后分表。比如我有个ip地址转地理位置的站，就是分成
255个表。
【在 g***t 的大作中提到】
: Zend vs. CakePhp vs. CI vs. Symphony
: 据说Symphony功能最强大，最适合大型网站。
: 但是啥是大型网站呢？到底大型网站的定义是什么？
: 还有另外一个问题，如果一个表格(table)的记录越来越多，多到非常庞大，那么应该
: 如何处理
|
