|
|
You're in the
sql server data warehouse
group:Please help!
sql server data warehouse:
A new Systems Architect is trying to tell me that a data warehouse typically
contains thousands of fact tables and hundreds of thousands of dimensions. So you know, my business is in the retail sector. I specifically asked if he meant THOUSANDS of MEMBERS, not dimensions, and he's sticking to his statement. Taking my warehouse in this sort of direction is going to spell disaster, it seems to me. Even if I fragmented every member into its own dimension, would I ever have 100,000 ?? I realize that it's theoretically possible for a warehouse to have that many fact tables and dimensions, but it's not what I've seen in the course of my work. I need to hear back from you folks, please. Is there any retail warehouse that would actually have hundreds of thousands of separate dimensional tables? If so, why? Is there any warehouse at all that would have so many dimensions. Thank you in advance for any help.
I did! I was all over that. He blew me off, saying to just trust him, with
his experience of having built twelve data warehouses. Which I haven't seen. I asked for examples, got nothing. I admit, I've only got a couple years of experience in warehousing, lots to learn ahead of me. However, I haven't seen anything in Kimball's books or the web that indicates the "popularity" of data warehouses with hundreds of thousands of dimensions. [quoted text, click to view] "Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in message news:%23iBXx8$QEHA.2216@TK2MSFTNGP12.phx.gbl... > > "J O Holloway" <respond.to.group@your.convenience> wrote in message > news:eOAvb4$QEHA.624@TK2MSFTNGP11.phx.gbl... > > A new Systems Architect is trying to tell me that a data warehouse > typically > > contains thousands of fact tables and hundreds of thousands of dimensions. > > Ask this person what "typical" means. Also ask for specific examples. > >
[quoted text, click to view] "J O Holloway" <respond.to.group@your.convenience> wrote in message news:eOAvb4$QEHA.624@TK2MSFTNGP11.phx.gbl... > A new Systems Architect is trying to tell me that a data warehouse typically > contains thousands of fact tables and hundreds of thousands of dimensions. Ask this person what "typical" means. Also ask for specific examples.
Thousands of fact tables and dimensions, wow, impressive. It is possible
for really really big datawarehouse. Typically, you combine 5 or 6 OLTP tables into one fact table, then you have about 15~20 dimensions per fact table, anything more than that would be nightmare for OLAP administrator. I built a datawarehousing solutions for a client couple months ago, it had 2 fact table and about 20 dimension tables, with about 15 members and another 20 calc. members. The OLTP DB was about 15 GB and OLAP blew it up to 50 GB and took about 3 days to fully process all the cubes, dimensions and aggregates. I would love the know how your system architect implemented his solution, what kind of hardware, what's the rebuild schedule, things like that. My biggest challenge was to keep those cubes as updated as possible, it just took too long. Here's the hardware/software I used: SQL 2000/AS 2000/Windows 2000 Compaq server with 4 proccessors + 8 GB RAM + SAN partitions Eric [quoted text, click to view] J O Holloway wrote: > I did! I was all over that. He blew me off, saying to just trust him, with > his experience of having built twelve data warehouses. > > Which I haven't seen. > > I asked for examples, got nothing. > > I admit, I've only got a couple years of experience in warehousing, lots to > learn ahead of me. However, I haven't seen anything in Kimball's books or > the web that indicates the "popularity" of data warehouses with hundreds of > thousands of dimensions. > > > > > > "Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in message > news:%23iBXx8$QEHA.2216@TK2MSFTNGP12.phx.gbl... > >>"J O Holloway" <respond.to.group@your.convenience> wrote in message >>news:eOAvb4$QEHA.624@TK2MSFTNGP11.phx.gbl... >> >>>A new Systems Architect is trying to tell me that a data warehouse >> >>typically >> >>>contains thousands of fact tables and hundreds of thousands of > > dimensions. > >> Ask this person what "typical" means. Also ask for specific examples. >> >> > > > -- Eric Li SQL DBA
One exception is that he could be using Inmon's methodolody. HIs approach is
a relational one, no t so far for "many" more tables than a Star model -- ALEJANDRO LEGUIZAMO MVP SQL - Colombia [quoted text, click to view] "Eric.Li" <anonymous@microsoftnews.org> wrote in message news:eh4k88MREHA.3012@tk2msftngp13.phx.gbl... > Thousands of fact tables and dimensions, wow, impressive. It is possible > for really really big datawarehouse. Typically, you combine 5 or 6 OLTP > tables into one fact table, then you have about 15~20 dimensions per > fact table, anything more than that would be nightmare for OLAP > administrator. I built a datawarehousing solutions for a client couple > months ago, it had 2 fact table and about 20 dimension tables, with > about 15 members and another 20 calc. members. The OLTP DB was about 15 > GB and OLAP blew it up to 50 GB and took about 3 days to fully process > all the cubes, dimensions and aggregates. I would love the know how your > system architect implemented his solution, what kind of hardware, what's > the rebuild schedule, things like that. My biggest challenge was to keep > those cubes as updated as possible, it just took too long. Here's the > hardware/software I used: > > SQL 2000/AS 2000/Windows 2000 > Compaq server with 4 proccessors + 8 GB RAM + SAN partitions > > Eric > > J O Holloway wrote: > > I did! I was all over that. He blew me off, saying to just trust him, with > > his experience of having built twelve data warehouses. > > > > Which I haven't seen. > > > > I asked for examples, got nothing. > > > > I admit, I've only got a couple years of experience in warehousing, lots to > > learn ahead of me. However, I haven't seen anything in Kimball's books or > > the web that indicates the "popularity" of data warehouses with hundreds of > > thousands of dimensions. > > > > > > > > > > > > "Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in message > > news:%23iBXx8$QEHA.2216@TK2MSFTNGP12.phx.gbl... > > > >>"J O Holloway" <respond.to.group@your.convenience> wrote in message > >>news:eOAvb4$QEHA.624@TK2MSFTNGP11.phx.gbl... > >> > >>>A new Systems Architect is trying to tell me that a data warehouse > >> > >>typically > >> > >>>contains thousands of fact tables and hundreds of thousands of > > > > dimensions. > > > >> Ask this person what "typical" means. Also ask for specific examples. > >> > >> > > > > > > > > > -- > Eric Li > SQL DBA > MCDBA
I can accept the idea of thousands of dimensions, maybe in some upscale
scientific application. This guy, I swear, said "There could be one hundred thousand dimension tables". I quote that verbatim. I asked if he meant the total number of members, or even the number of cells that would result from building the cube. Nope .. he meant _tables_. And we're in a fairly simple retail environment. Then he went on to say that SQL Server can't do real-time updating of a cube (which it can, I believe, in the Enterprise version), and that Microsoft is still recommending snowflake schemas (which I haven't seen, but is irrelevant, since I'm following Kimball's recommendations and not Microsoft's in designing the warehouse). [quoted text, click to view] "Alejandro Leguizamo (MVP)" <noone@noone.com> wrote in message news:%23isrOXOREHA.808@tk2msftngp13.phx.gbl... > One exception is that he could be using Inmon's methodolody. HIs approach is > a relational one, no t so far for "many" more tables than a Star model > > -- > ALEJANDRO LEGUIZAMO > MVP SQL - Colombia > > > "Eric.Li" <anonymous@microsoftnews.org> wrote in message > news:eh4k88MREHA.3012@tk2msftngp13.phx.gbl... > > Thousands of fact tables and dimensions, wow, impressive. It is possible > > for really really big datawarehouse. Typically, you combine 5 or 6 OLTP > > tables into one fact table, then you have about 15~20 dimensions per > > fact table, anything more than that would be nightmare for OLAP > > administrator. I built a datawarehousing solutions for a client couple > > months ago, it had 2 fact table and about 20 dimension tables, with > > about 15 members and another 20 calc. members. The OLTP DB was about 15 > > GB and OLAP blew it up to 50 GB and took about 3 days to fully process > > all the cubes, dimensions and aggregates. I would love the know how your > > system architect implemented his solution, what kind of hardware, what's > > the rebuild schedule, things like that. My biggest challenge was to keep > > those cubes as updated as possible, it just took too long. Here's the > > hardware/software I used: > > > > SQL 2000/AS 2000/Windows 2000 > > Compaq server with 4 proccessors + 8 GB RAM + SAN partitions > > > > Eric > > > > J O Holloway wrote: > > > I did! I was all over that. He blew me off, saying to just trust him, > with > > > his experience of having built twelve data warehouses. > > > > > > Which I haven't seen. > > > > > > I asked for examples, got nothing. > > > > > > I admit, I've only got a couple years of experience in warehousing, lots > to > > > learn ahead of me. However, I haven't seen anything in Kimball's books > or > > > the web that indicates the "popularity" of data warehouses with hundreds > of > > > thousands of dimensions. > > > > > > > > > > > > > > > > > > "Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in message > > > news:%23iBXx8$QEHA.2216@TK2MSFTNGP12.phx.gbl... > > > > > >>"J O Holloway" <respond.to.group@your.convenience> wrote in message > > >>news:eOAvb4$QEHA.624@TK2MSFTNGP11.phx.gbl... > > >> > > >>>A new Systems Architect is trying to tell me that a data warehouse > > >> > > >>typically > > >> > > >>>contains thousands of fact tables and hundreds of thousands of > > > > > > dimensions. > > > > > >> Ask this person what "typical" means. Also ask for specific > examples. > > >> > > >> > > > > > > > > > > > > > > > -- > > Eric Li > > SQL DBA > > MCDBA > >
"One hundred thousand dimension tables", does he mean all the members
inside that dimension? Or actually dimension tables? Either way, I won't use this datawarehouse. First, if he's using cubes, it will take FOREVER to process unless the fact tables are super small ( less than 1000 records per table). Second, if he's not using star/snowflake schema (like Alejandro suggested), in that case, it's not actual OLAP solution. It's basically OLTP structure. Even that, I can't imagine you have a DB with hundred thousand dimension tables, not to mention fact tables, if I am the DB admin. I will probably shoot the DB designer myself. Then think about it from users' point of view and then security. And I haven't touched the aggregates, calculate measures,etc. I would really love to have him show me that warehouse. True, AS is not real time, which means you have to reprocess the cube to reflect the latest changes. But OLAP never meant to be real time. One solution to deal with real time is cube partitions and it can get rather complicated, but possible. Your architect may know more than I do, but I would like to see how he did it instead of just 'words' Eric -- Eric Li SQL DBA MCDBA [quoted text, click to view] J O Holloway wrote: > I can accept the idea of thousands of dimensions, maybe in some upscale > scientific application. > > This guy, I swear, said "There could be one hundred thousand dimension > tables". I quote that verbatim. I asked if he meant the total number of > members, or even the number of cells that would result from building the > cube. Nope .. he meant _tables_. And we're in a fairly simple retail > environment. > > Then he went on to say that SQL Server can't do real-time updating of a cube > (which it can, I believe, in the Enterprise version), and that Microsoft is > still recommending snowflake schemas (which I haven't seen, but is > irrelevant, since I'm following Kimball's recommendations and not > Microsoft's in designing the warehouse). > > > "Alejandro Leguizamo (MVP)" <noone@noone.com> wrote in message > news:%23isrOXOREHA.808@tk2msftngp13.phx.gbl... > >>One exception is that he could be using Inmon's methodolody. HIs approach > > is > >>a relational one, no t so far for "many" more tables than a Star model >> >>-- >>ALEJANDRO LEGUIZAMO >>MVP SQL - Colombia >> >> >>"Eric.Li" <anonymous@microsoftnews.org> wrote in message >>news:eh4k88MREHA.3012@tk2msftngp13.phx.gbl... >> >>>Thousands of fact tables and dimensions, wow, impressive. It is possible >>>for really really big datawarehouse. Typically, you combine 5 or 6 OLTP >>>tables into one fact table, then you have about 15~20 dimensions per >>>fact table, anything more than that would be nightmare for OLAP >>>administrator. I built a datawarehousing solutions for a client couple >>>months ago, it had 2 fact table and about 20 dimension tables, with >>>about 15 members and another 20 calc. members. The OLTP DB was about 15 >>>GB and OLAP blew it up to 50 GB and took about 3 days to fully process >>>all the cubes, dimensions and aggregates. I would love the know how your >>>system architect implemented his solution, what kind of hardware, what's >>>the rebuild schedule, things like that. My biggest challenge was to keep >>>those cubes as updated as possible, it just took too long. Here's the >>>hardware/software I used: >>> >>>SQL 2000/AS 2000/Windows 2000 >>>Compaq server with 4 proccessors + 8 GB RAM + SAN partitions >>> >>>Eric >>> >>>J O Holloway wrote: >>> >>>>I did! I was all over that. He blew me off, saying to just trust > > him, > >>with >> >>>>his experience of having built twelve data warehouses. >>>> >>>>Which I haven't seen. >>>> >>>>I asked for examples, got nothing. >>>> >>>>I admit, I've only got a couple years of experience in warehousing, > > lots > >>to >> >>>>learn ahead of me. However, I haven't seen anything in Kimball's > > books > >>or >> >>>>the web that indicates the "popularity" of data warehouses with > > hundreds > >>of >> >>>>thousands of dimensions. >>>> >>>> >>>> >>>> >>>> >>>>"Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in > > message > >>>>news:%23iBXx8$QEHA.2216@TK2MSFTNGP12.phx.gbl... >>>> >>>> >>>>>"J O Holloway" <respond.to.group@your.convenience> wrote in message >>>>>news:eOAvb4$QEHA.624@TK2MSFTNGP11.phx.gbl... >>>>> >>>>> >>>>>>A new Systems Architect is trying to tell me that a data warehouse >>>>> >>>>>typically >>>>> >>>>> >>>>>>contains thousands of fact tables and hundreds of thousands of >>>> >>>>dimensions. >>>> >>>> >>>>> Ask this person what "typical" means. Also ask for specific >> >>examples. >> >>>>> >>>> >>>> >>> >>>-- >>>Eric Li >>>SQL DBA >>>MCDBA >> >> > >
One more thing to add, my client is in food/drink industry and it is
BIG, very BIG, and I am pretty sure you carry their products too. Even for a size like that. My dimension tables have only 7 levels hierarchy and less than 1000 members. Eric -- Eric Li SQL DBA MCDBA [quoted text, click to view] J O Holloway wrote:
> I can accept the idea of thousands of dimensions, maybe in some upscale > scientific application. > > This guy, I swear, said "There could be one hundred thousand dimension > tables". I quote that verbatim. I asked if he meant the total number of > members, or even the number of cells that would result from building the > cube. Nope .. he meant _tables_. And we're in a fairly simple retail > environment. > > Then he went on to say that SQL Server can't do real-time updating of a cube > (which it can, I believe, in the Enterprise version), and that Microsoft is > still recommending snowflake schemas (which I haven't seen, but is > irrelevant, since I'm following Kimball's recommendations and not > Microsoft's in designing the warehouse). > > > "Alejandro Leguizamo (MVP)" <noone@noone.com> wrote in message > news:%23isrOXOREHA.808@tk2msftngp13.phx.gbl... > >>One exception is that he could be using Inmon's methodolody. HIs approach > > is > >>a relational one, no t so far for "many" more tables than a Star model >> >>-- >>ALEJANDRO LEGUIZAMO >>MVP SQL - Colombia >> >> >>"Eric.Li" <anonymous@microsoftnews.org> wrote in message >>news:eh4k88MREHA.3012@tk2msftngp13.phx.gbl... >> >>>Thousands of fact tables and dimensions, wow, impressive. It is possible >>>for really really big datawarehouse. Typically, you combine 5 or 6 OLTP >>>tables into one fact table, then you have about 15~20 dimensions per >>>fact table, anything more than that would be nightmare for OLAP >>>administrator. I built a datawarehousing solutions for a client couple >>>months ago, it had 2 fact table and about 20 dimension tables, with >>>about 15 members and another 20 calc. members. The OLTP DB was about 15 >>>GB and OLAP blew it up to 50 GB and took about 3 days to fully process >>>all the cubes, dimensions and aggregates. I would love the know how your >>>system architect implemented his solution, what kind of hardware, what's >>>the rebuild schedule, things like that. My biggest challenge was to keep >>>those cubes as updated as possible, it just took too long. Here's the >>>hardware/software I used: >>> >>>SQL 2000/AS 2000/Windows 2000 >>>Compaq server with 4 proccessors + 8 GB RAM + SAN partitions >>> >>>Eric >>> >>>J O Holloway wrote: >>> >>>>I did! I was all over that. He blew me off, saying to just trust > > him, > >>with >> >>>>his experience of having built twelve data warehouses. >>>> >>>>Which I haven't seen. >>>> >>>>I asked for examples, got nothing. >>>> >>>>I admit, I've only got a couple years of experience in warehousing, > > lots > >>to >> >>>>learn ahead of me. However, I haven't seen anything in Kimball's > > books > >>or >> >>>>the web that indicates the "popularity" of data warehouses with > > hundreds > >>of >> >>>>thousands of dimensions. >>>> >>>> >>>> >>>> >>>> >>>>"Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in > > message > >>>>news:%23iBXx8$QEHA.2216@TK2MSFTNGP12.phx.gbl... >>>> >>>> >>>>>"J O Holloway" <respond.to.group@your.convenience> wrote in message >>>>>news:eOAvb4$QEHA.624@TK2MSFTNGP11.phx.gbl... >>>>> >>>>> >>>>>>A new Systems Architect is trying to tell me that a data warehouse >>>>> >>>>>typically >>>>> >>>>> >>>>>>contains thousands of fact tables and hundreds of thousands of >>>> >>>>dimensions. >>>> >>>> >>>>> Ask this person what "typical" means. Also ask for specific >> >>examples. >> >>>>> >>>> >>>> >>> >>>-- >>>Eric Li >>>SQL DBA >>>MCDBA >> >> > >
Thank you very much. If I ever pull an example out of this guy, I'll post
it. Currently, it's become a political battle of sorts. Thanks to all for the insight. [quoted text, click to view] "Eric.Li" <anonymous@microsoftnews.org> wrote in message news:OP8JdZPREHA.1048@tk2msftngp13.phx.gbl... > One more thing to add, my client is in food/drink industry and it is > BIG, very BIG, and I am pretty sure you carry their products too. Even > for a size like that. My dimension tables have only 7 levels hierarchy > and less than 1000 members. > > Eric > > -- > Eric Li > SQL DBA > MCDBA > > > J O Holloway wrote: > > > I can accept the idea of thousands of dimensions, maybe in some upscale > > scientific application. > > > > This guy, I swear, said "There could be one hundred thousand dimension > > tables". I quote that verbatim. I asked if he meant the total number of > > members, or even the number of cells that would result from building the > > cube. Nope .. he meant _tables_. And we're in a fairly simple retail > > environment. > > > > Then he went on to say that SQL Server can't do real-time updating of a cube > > (which it can, I believe, in the Enterprise version), and that Microsoft is > > still recommending snowflake schemas (which I haven't seen, but is > > irrelevant, since I'm following Kimball's recommendations and not > > Microsoft's in designing the warehouse). > > > > > > "Alejandro Leguizamo (MVP)" <noone@noone.com> wrote in message > > news:%23isrOXOREHA.808@tk2msftngp13.phx.gbl... > > > >>One exception is that he could be using Inmon's methodolody. HIs approach > > > > is > > > >>a relational one, no t so far for "many" more tables than a Star model > >> > >>-- > >>ALEJANDRO LEGUIZAMO > >>MVP SQL - Colombia > >> > >> > >>"Eric.Li" <anonymous@microsoftnews.org> wrote in message > >>news:eh4k88MREHA.3012@tk2msftngp13.phx.gbl... > >> > >>>Thousands of fact tables and dimensions, wow, impressive. It is possible > >>>for really really big datawarehouse. Typically, you combine 5 or 6 OLTP > >>>tables into one fact table, then you have about 15~20 dimensions per > >>>fact table, anything more than that would be nightmare for OLAP > >>>administrator. I built a datawarehousing solutions for a client couple > >>>months ago, it had 2 fact table and about 20 dimension tables, with > >>>about 15 members and another 20 calc. members. The OLTP DB was about 15 > >>>GB and OLAP blew it up to 50 GB and took about 3 days to fully process > >>>all the cubes, dimensions and aggregates. I would love the know how your > >>>system architect implemented his solution, what kind of hardware, what's > >>>the rebuild schedule, things like that. My biggest challenge was to keep > >>>those cubes as updated as possible, it just took too long. Here's the > >>>hardware/software I used: > >>> > >>>SQL 2000/AS 2000/Windows 2000 > >>>Compaq server with 4 proccessors + 8 GB RAM + SAN partitions > >>> > >>>Eric > >>> > >>>J O Holloway wrote: > >>> > >>>>I did! I was all over that. He blew me off, saying to just trust > > > > him, > > > >>with > >> > >>>>his experience of having built twelve data warehouses. > >>>> > >>>>Which I haven't seen. > >>>> > >>>>I asked for examples, got nothing. > >>>> > >>>>I admit, I've only got a couple years of experience in warehousing, > > > > lots > > > >>to > >> > >>>>learn ahead of me. However, I haven't seen anything in Kimball's > > > > books > > > >>or > >> > >>>>the web that indicates the "popularity" of data warehouses with > > > > hundreds > > > >>of > >> > >>>>thousands of dimensions. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>"Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in > > > > message > > > >>>>news:%23iBXx8$QEHA.2216@TK2MSFTNGP12.phx.gbl... > >>>> > >>>> > >>>>>"J O Holloway" <respond.to.group@your.convenience> wrote in message > >>>>>news:eOAvb4$QEHA.624@TK2MSFTNGP11.phx.gbl... > >>>>> > >>>>> > >>>>>>A new Systems Architect is trying to tell me that a data warehouse > >>>>> > >>>>>typically > >>>>> > >>>>> > >>>>>>contains thousands of fact tables and hundreds of thousands of > >>>> > >>>>dimensions. > >>>> > >>>> > >>>>> Ask this person what "typical" means. Also ask for specific > >> > >>examples. > >> > >>>>> > >>>> > >>>> > >>> > >>>-- > >>>Eric Li > >>>SQL DBA > >>>MCDBA > >> > >> > > > > >
I agre 100% with Eric. Be very carefull on one point. OLAP was primarily
created to give SOLUTIONS to the BDM"s of the organization. It's NOT practical from that point of view, that of "hundreds" of tables. Be sure to make a point on ease of use and understandability from an end users perspective. Unfortunatelly i have seen many DW projects to crash because that error. Forgeting your customer :( I use to make a joke, even when it's real: My mom has no idea of technology (she works in banking) i ALWAYS show my models to my mom. If se gets it, then it's fine!!! ;) By the way, i adore my mom, she is my first challenging QA process -- ALEJANDRO LEGUIZAMO MVP SQL - Colombia [quoted text, click to view] "J O Holloway" <respond.to.group@your.convenience> wrote in message news:uks54iPREHA.2520@TK2MSFTNGP11.phx.gbl... > Thank you very much. If I ever pull an example out of this guy, I'll post > it. > > Currently, it's become a political battle of sorts. Thanks to all for the > insight. > > > "Eric.Li" <anonymous@microsoftnews.org> wrote in message > news:OP8JdZPREHA.1048@tk2msftngp13.phx.gbl... > > One more thing to add, my client is in food/drink industry and it is > > BIG, very BIG, and I am pretty sure you carry their products too. Even > > for a size like that. My dimension tables have only 7 levels hierarchy > > and less than 1000 members. > > > > Eric > > > > -- > > Eric Li > > SQL DBA > > MCDBA > > > > > > J O Holloway wrote: > > > > > I can accept the idea of thousands of dimensions, maybe in some upscale > > > scientific application. > > > > > > This guy, I swear, said "There could be one hundred thousand dimension > > > tables". I quote that verbatim. I asked if he meant the total number > of > > > members, or even the number of cells that would result from building the > > > cube. Nope .. he meant _tables_. And we're in a fairly simple retail > > > environment. > > > > > > Then he went on to say that SQL Server can't do real-time updating of a > cube > > > (which it can, I believe, in the Enterprise version), and that Microsoft > is > > > still recommending snowflake schemas (which I haven't seen, but is > > > irrelevant, since I'm following Kimball's recommendations and not > > > Microsoft's in designing the warehouse). > > > > > > > > > "Alejandro Leguizamo (MVP)" <noone@noone.com> wrote in message > > > news:%23isrOXOREHA.808@tk2msftngp13.phx.gbl... > > > > > >>One exception is that he could be using Inmon's methodolody. HIs > approach > > > > > > is > > > > > >>a relational one, no t so far for "many" more tables than a Star model > > >> > > >>-- > > >>ALEJANDRO LEGUIZAMO > > >>MVP SQL - Colombia > > >> > > >> > > >>"Eric.Li" <anonymous@microsoftnews.org> wrote in message > > >>news:eh4k88MREHA.3012@tk2msftngp13.phx.gbl... > > >> > > >>>Thousands of fact tables and dimensions, wow, impressive. It is > possible > > >>>for really really big datawarehouse. Typically, you combine 5 or 6 OLTP > > >>>tables into one fact table, then you have about 15~20 dimensions per > > >>>fact table, anything more than that would be nightmare for OLAP > > >>>administrator. I built a datawarehousing solutions for a client couple > > >>>months ago, it had 2 fact table and about 20 dimension tables, with > > >>>about 15 members and another 20 calc. members. The OLTP DB was about 15 > > >>>GB and OLAP blew it up to 50 GB and took about 3 days to fully process > > >>>all the cubes, dimensions and aggregates. I would love the know how > your > > >>>system architect implemented his solution, what kind of hardware, > what's > > >>>the rebuild schedule, things like that. My biggest challenge was to > keep > > >>>those cubes as updated as possible, it just took too long. Here's the > > >>>hardware/software I used: > > >>> > > >>>SQL 2000/AS 2000/Windows 2000 > > >>>Compaq server with 4 proccessors + 8 GB RAM + SAN partitions > > >>> > > >>>Eric > > >>> > > >>>J O Holloway wrote: > > >>> > > >>>>I did! I was all over that. He blew me off, saying to just trust > > > > > > him, > > > > > >>with > > >> > > >>>>his experience of having built twelve data warehouses. > > >>>> > > >>>>Which I haven't seen. > > >>>> > > >>>>I asked for examples, got nothing. > > >>>> > > >>>>I admit, I've only got a couple years of experience in warehousing, > > > > > > lots > > > > > >>to > > >> > > >>>>learn ahead of me. However, I haven't seen anything in Kimball's > > > > > > books > > > > > >>or > > >> > > >>>>the web that indicates the "popularity" of data warehouses with > > > > > > hundreds > > > > > >>of > > >> > > >>>>thousands of dimensions. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>"Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in > > > > > > message > > > > > >>>>news:%23iBXx8$QEHA.2216@TK2MSFTNGP12.phx.gbl... > > >>>> > > >>>> > > >>>>>"J O Holloway" <respond.to.group@your.convenience> wrote in message > > >>>>>news:eOAvb4$QEHA.624@TK2MSFTNGP11.phx.gbl... > > >>>>> > > >>>>> > > >>>>>>A new Systems Architect is trying to tell me that a data warehouse > > >>>>> > > >>>>>typically > > >>>>> > > >>>>> > > >>>>>>contains thousands of fact tables and hundreds of thousands of > > >>>> > > >>>>dimensions. > > >>>> > > >>>> > > >>>>> Ask this person what "typical" means. Also ask for specific > > >> > > >>examples. > > >> > > >>>>> > > >>>> > > >>>> > > >>> > > >>>-- > > >>>Eric Li > > >>>SQL DBA > > >>>MCDBA > > >> > > >> > > > > > > > > > >
Don't see what you're looking for? Try a search.
|
January 2003
March 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |