Am Donnerstag, 14. Februar 2013, 22:20:51 schrieb Cédric Krier: [...]
> > > > This sounds to me as some kind of pre-aggregation is made with this > > > > account: During a business transaction some information is written > > > > into > > > > this 'account' or whatever we want to call it (other ERP call this > > > > 'information-structures'). Afterwards is it much faster to report on > > > > this > > > > than running a report over all sales documents. So it is a kind of > > > > light > > > > BI-structure. > > > > > > Still wrong solution, better to have a *real* BI. > > > > Well, a real BI is in most cases not online and realtime - ETL is mostly > > only once a day. And requires a second system. > > Perhaps but only on big system, for SME you can run such queries on the > production database (this is the job of a database). Agree, in small environments it does not matter. There a query can do the job. If you get bigger, you need to think about something different. And here you can preaggregate information or bolt-on a BI-system. Or take into account that the online query over all (sales-) records kills your db-system - especially if not only one, but 50 users run a query at the same time. > But the big flaw in what you propose is that it doesn't survive to > change in the configuration, if a product was wrongly configured, you > can not fix it unless you update all the analytic move but how can you > know about it? You will need to write the same queries as I proposed so > it is useless to do analytic accounting for such purpose. Thats right. Other ERP systems have solved this with a so called statistics rebuild, a job that simulates the postings with the new settings. It runs in the background and fills the analytic account, or whatever we call the reporting structure. > So I still maintain that duplicate information is *WRONG*. A BI system is duplicating information as well, just in a different system. You need to run your ETL as well if configuration changes, or additional key figures have to be calculated. [eod from my side] Cheers Axel -- Dr.-Ing. Axel K. Braun Mobile: +49.173.7003.154 VoIP/Skype: axxite PGP Fingerprint: CB03 964D 1CFA E87B AA63 53F3 1BD6 F53A EB48 EF22 Public Key available at http://www.axxite.com/[email protected] This mail was *not scanned* before sending. It was sent from a secure Linux-Desktop: ThinkPad T520 OS: openSUSE 12.2 (x86_64) Kernel: 3.4.28-2.20-desktop KDE: 4.10.00 "release 546"
signature.asc
Description: This is a digitally signed message part.
