MySQL preps business upgrade

TalkBack 16 of 19:

Next »

« Previous

• Thread View
• Flat View

You're Just Wrong...

on so many fronts here. You seem very out of touch with main-stream database thought, and very vocal about your marginal opinions.

I recently attended the TDWI data warehousing conference, and listened to and spoke with many vendors and leaders in the industry. I can say that we all agree that getting to one version of the truth across many historical data stores is indeed a big problem, but normalization isn't the answer to it. The answer is data scrubbing, data profiling, and in the long-term enterprise data integration efforts. Fire up google and find what you can read on EAI. Once you understand the issues, we can talk intelligently about data warehousing. You're not there yet. You're still one of the weenies brought up on normalization whining about how messy the real world is.

Real data warehousing efforts duplicate data all over the place. You are simply wrong that historical data is updated because you haven't understood what historical data is. Data warehousing data is most often made up from snapshot dumps from transactional systems. It's dead data. There will be no more transactions on it, and it will never be updated. You need to read some elementary material, such as any number of introductory books on data warehousing by Ralph Kimball or Inman.

You are just completely wrong again about triggers. Triggers are comming used to implement constraints. CASE tools like Embarcadero ER studio or ERWin auto generate trigger code to enforce data integrity constraints that cannot be implemented by checks or foreign keys. You do some reading in the doc on triggers that came with you RDBMS of choice, and see if you can't figure out how to implement the equivalent of a foreign key contraint with an INSERT and UPDATE trigger. After you work through that exercise, it will finally dawn on you how you could use triggers for other sorts of constraints. Congratulations!

You're across the board declaration that all data consistency and integrity constraints should be done in the database flies in the face of many successfully implemented systems. Particularly those that want to code to a very basic SQL standard to allow easily switching which back end DBMS is used. And it is common practice to implement some consistency constraits that are performance inhibiting on the DB as application code. Again, welcome to the real world.

As for your self-rightous attitude about your "advanced" understanding of what relational means, from what I've been able to gather from our discussions here, you have a self-image of your own database skills and aptitudes that really is based only on contemplating your own navel. I think you should spend more time listening to what other knowledgable and experienced people are saying, and less time spouting off about how no one but your little cadre understands what a relational database "really means."

Posted by: jcg_z   Posted on: 10/21/05 You are currently: a Guest | Members login | Terms of Use

Alert moderator to an offensive message

Subscribe to this discussion via Email or RSS

SponsoredWhite Papers, Webcasts, and Downloads

• Server Consolidation and Containment With Virtual Infrastructure VMware To meet the constant demand to deploy, maintain and grow a broad array of ... Download Now
• CLOUD-CLIENT ENTERPRISE SECURITY IMPACT REPORT: INCREASED PROTECTION AT A LOWER COST Trend Micro Malware, spam and other threats on the Internet are an increasing problem ... Download Now
• Security Explorer for Exchange Version 7.0.2 ScriptLogic Security Explorer for Exchange is a powerful, graphical solution for ... Download Now