then they hand it to a BI dev who can validate, add data sources, add security/perspectives/partitioning, and deploy. let a user build an excel PowerPivot model, teams can refine it. The development lifecycle is much more agile. but simple parsing/etc is basically effortless sure, a lot of the conditionals can be just as nasty. so you can more aggressively refresh throughout the day.ĭAX is often easier than MDX. which is not likely very resource intensive (IO intensive, but not CPU or memory). so your scheduled effort is to simply reload the current partition (hour/day/etc) from source. So many things wrong with it, and no apparent interest in fixing them. The database cache file (dbmdl) gets corrupted if you switch git branches too much and isn't wiped when you Build->Clean like every self-respecting intermediate object should. No proper solution for managing lookup data. That inscrutable and barely-documented XML format. Designers that pop open and grind for minutes for editing a plain text file containing a table definition. No support for SSRS in MSBuild/MSDeploy so you can publish your SSRS projects just like every other VS project. No support for NuGet packages so SSDT projects can reference other DACPACs. Infuriating publish workflow where it doesn't ask you about parameters until it's spent 20 minutes grinding on a problem. Getting Invoke-SqlCmd working on Powershell is a goddamned nightmare if you want to have your build server execute SqlCmd scripts. It's a memory pig with long single-threaded build-times for large legacy projects (and is occasionally throws an OOM), it's impossible to know what folder SqlPackage.exe lives in on a given machine that's trying to deploy anything.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |