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。
|
|
