|
|
Posted by Tony Rogerson on 12/04/06 08:08
> Can you get a DW package, which would handle this stuff much better
> than an SQL aimed at OLTP? Or will the boss scream about the budget?
> DW is a really diffrent game and that explains some of your code
> decisions.
As usual you have not done your research on this, simply installing
Microsoft SQL Server and you will quickly realise (part of the set up) that
the product SQL Server is actually a name given to group the data engine
offering from Microsoft - relational engine, dimensioanl/aggregation/data
mining engine (analysis services), etl (integration services) messaging
(service broker).
It is a fundemental principal of a good consultant to do their research, for
most of us it comes naturally for you it obviously doesn't.
--
Tony Rogerson
SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL
Server Consultant
http://sqlserverfaq.com - free video tutorials
"--CELKO--" <jcelko212@earthlink.net> wrote in message
news:1165169193.259749.173140@80g2000cwy.googlegroups.com...
>>> 1. I use an ETL tool, it creates the DDL, I just copied and pasted. <<
>
> There are some open source "pretty printers" for SQL, which would be
> good to have around the shop. So many of the packages generate code
> for a compiler to use and not for a human being to read.
>
>>> 3. This is a data warehouse, not an operational system. <<
>
> Can you get a DW package, which would handle this stuff much better
> than an SQL aimed at OLTP? Or will the boss scream about the budget?
> DW is a really diffrent game and that explains some of your code
> decisions.
>
>>>. the business keys for the table im trying to update is ADMREP_ID,
>>>SESSION_ID and
> SESSION_DAY. I concatinate them into a single field [sic] so I have a
> unique key. <<
>
> Here we are back to the conceptual problems. Columns are not fields,
> nothing like them at all. The concatenation is a bad idea and you
> should use a three-column key instead.
>
>>> 6. Yes, it is a Y/N field. Tables that are slowly changing dimensions
>>> have start_date, end_date, update_date and curr_ind. Y is the current
>>> record [sic] as it is in the operational system. <<
>
> You can get that fact from the dates, can't you? There should be no
> need for flags in a DW. Also, that implies that the DW is getting live
> feeds from operations. Is that true?
>
>>> 7. This is an area that I would like to have more control within the ETL
>>> tool. it looks at the data and determines what type to create. Of course
>>> I could create the tables ahead of time, and not let the tool create
>>> them for me. <<
>
> That sounds like the answer. The cost of casting, the chance for
> errors, etc. is just too much. Can the ETL tool load the tables
> without having to immediately re-index them as it goes?
>
>>> Thanks for the constructive suggestions Celko. I've learned a lot on how
>>> I might change the UPdate to run faster...no wait a minute, you just
>>> finished berating me and came just sort of calling me stupid... Never
>>> mind. <<
>
> LOL!!
>
Navigation:
[Reply to this message]
|