k*****i 发帖数: 9 | 1 多谢!
这样一来不是price_record表的记录有很多,表很长很长,
应该等于"天数(365)"*"股票市数目"=...? 表会不会太大.
咱先不考虑COMPANY PROFILE TABLE . | k*****i 发帖数: 9 | 2 是不是表的数目越少越好,在数据库设计的时候.
然后让SQL去处理这个大表而得到中间结果,而不是直接设计无数小表以直接利用? | aw 发帖数: 127 | 3 这个不是绝对的,但你这个情况几个表就够了,找本数据库的书看看,你会学到很多。
【在 k*****i 的大作中提到】 : 是不是表的数目越少越好,在数据库设计的时候. : 然后让SQL去处理这个大表而得到中间结果,而不是直接设计无数小表以直接利用?
| aw 发帖数: 127 | 4 看你的情况,用EXCEL而非ACCESS可能目前更适合。
在数据库里,如果一个表数据太多查询太慢,可以先多加INDEX,进一步还可以用PARTITI
ON。
【在 k*****i 的大作中提到】 : 多谢! : 这样一来不是price_record表的记录有很多,表很长很长, : 应该等于"天数(365)"*"股票市数目"=...? 表会不会太大. : 咱先不考虑COMPANY PROFILE TABLE .
| c**g 发帖数: 274 | 5 Reading this thread, remind me one funny thing. My DBA boss' desk
is next to me and I can hear him on phone explaining why sybase/orcale/
database is not excel/table to business managers once every
couples of days, hehe.
【在 aw 的大作中提到】 : 看你的情况,用EXCEL而非ACCESS可能目前更适合。 : 在数据库里,如果一个表数据太多查询太慢,可以先多加INDEX,进一步还可以用PARTITI : ON。
|
|