Tag Info

New answers tagged

1

There's no answer that applies in all cases. In general, however... If the lookup list is small and you can cache it(or use a cache data source), there's not much performance penalty to doing it in SSIS. If you want crossref a list of 50 location codes to names of cities, go for it. It's nice to see all the process on-screen in one place, rather than buried ...


1

This is a perfectly valid practice, though it's more commonly used for inserts than updates. This is discussed elsewhere on Stack Exchange (e.g., http://programmers.stackexchange.com/a/78598/25946). It's worth confirming, though, that the whole time required for "create index, update, drop index" really is less than making the update without indices. You ...


6

Building temporary indexes for ETL jobs is not necessarily bad practice, as the index builds are fairly quick. Where it might not be so efficient is if you have relatively small incremental updates on very large tables, but it sounds like this is not the case here. The only caveat is if you expect the tables to grow substantially with time. If they are ...


2

The only thing which I can think of which could be bad is that while building indexes new inserts/updates on the relevant tables could be problematic. But if there is no use-case for changing the data while building indexes it is a fast and viable approach. You save time and space.


7

If it works for you then it's a good practice. There are basically no hard rules for databases.


1

For very large Databases you can always use the compression method in SQL server 2012. That will help a lot in reducing down the backup size of the database: For how to use and more on this refer to below link: http://www.sqlservergeeks.com/sql-server-database-backup-compression-faster-disaster-recovery/ To avail the space, make sure you're backup ...


1

A data warehouse exists to provide the business with usable data. A NULL value does not tell your users anything; you can do better. Also, a NULL value will drop out when joining your fact table to a dimension table, causing undercount. In your dimension table, include a record for each scenario where a transactional database might store a NULL. All of ...



Top 50 recent answers are included