Re: [Semi-OT] Views, Stored Procedures, and Class::DBI

~~First off, MySQL 4.0 supports views.~~ (I'm wrong here.) MySQL 5.0 supports stored procedures, triggers and ~~updateable~~ views. As MySQL 5.0 is going to be released any day now, that canard is gone.

As for why you would use each feature, here's a quick primer:

Triggers - these are used to do something whenever something else happens. Generally, they're used for maintaining data integrity with something outside the database or for some sort of referential integrity that standard foreign keys cannot do. My opinion is that if you are depending on them, you either don't trust your programmers or you build it wrong.
Stored Procedures - these are little programs in your database. They're very useful when doing lots and lots of crazy stuff that's DB specific. I've used them and they're pretty nice, especially when you have multiple apps in multiple languages hitting the same database. Frankly, I don't work on those kinds of things anymore, so I don't use them.
Views - These are great. Often, you have a table with a lot of information, but some of it is sensitive. So, you provide a view for those users who aren't allowed to see the whole thing. This is useful for applications, as well. If you can limit what an app is allowed to do, you limit what the attacker who cracked your app can do.
Also, they're great for frequent joins. Let's say you have a join of three tables that you do on a regular basis. By providing a view for that join, you can reduce the query time because the DB will keep that resultset around as a temporary table.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re: [Semi-OT] Views, Stored Procedures, and Class::DBI

Replies are listed 'Best First'.
Re^2: [Semi-OT] Views, Stored Procedures, and Class::DBI by tilly (Archbishop) on Oct 19, 2005 at 06:13 UTC
Triggers ... My opinion is that if you are depending on them, you either don't trust your programmers or you build it wrong. You say it like that's a bad thing. :-) There are times when you really don't want to trust programmers. For instance one common use of triggers is for auditing changes. You don't want to be in a position of having a change in your financial data that you can't explain. Depending on your database (I've seen it demonstrated with Oracle), it is possible to set things up so that nobody - including the DBA - can make a change without it being audited. Sure, you can turn auditing off. But the fact that you turned it off will itself get logged. Usually this would be overkill. But there are situations where you really do need to be able to trust, but verify to this level.	[reply]
Re^3: [Semi-OT] Views, Stored Procedures, and Class::DBI by mescanne (Sexton) on Oct 19, 2005 at 12:16 UTC
I think you have it exactly right, but I'd like to expand on the example. Imagine an organization that has a sizeable group in charge solely of the database -- including replication across many servers, rational backup schemes, auditing and authorizing changes, optimizing queries and maintaining performance, etc. -- and then a wide variety of other groups which both develop applications as well as users using a variety of SQL reporting tools. The entire exercise can get exceedingly complicated and it can be pretty clear how triggers and stored procedures can be immensely useful for the DB group to maintain control. From a one database to one application relationship these tools don't seem to make as much sense. Mark	[reply]
Re^3: [Semi-OT] Views, Stored Procedures, and Class::DBI by dragonchild (Archbishop) on Oct 19, 2005 at 13:18 UTC
You say it like that's a bad thing. :-) grins It's not a bad thing. In fact, it's often the only recourse a DBA has, precisely for the kind of reason you're talking about. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^2: [Semi-OT] Views, Stored Procedures, and Class::DBI by jgallagher (Pilgrim) on Oct 18, 2005 at 15:34 UTC
If you create a view for a frequent join, what would be the best way to utilize that from CDBI? I would guess either (1) treating it as a separate table or (2) writing a "search view, map results into the 'real' table types" sub. Perhaps choose (1) if you don't have access to the base tables and (2) if you do?	[reply]
Re^2: [Semi-OT] Views, Stored Procedures, and Class::DBI by diotalevi (Canon) on Oct 18, 2005 at 15:39 UTC
So the views are updatable then?	[reply]
Re^3: [Semi-OT] Views, Stored Procedures, and Class::DBI by dragonchild (Archbishop) on Oct 18, 2005 at 15:55 UTC
That was one of the major features in MySQL 5.0 - the others being triggers, stored procedures, and the NDB table type. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^2: [Semi-OT] Views, Stored Procedures, and Class::DBI by adrianh (Chancellor) on Oct 19, 2005 at 14:15 UTC
MySQL 5.0 supports stored procedures, triggers and ... views. As MySQL 5.0 is going to be released any day now, that canard is gone. Depends what you want to use them for. See the MySQL Feature Restrictions. I'm not even sure it's a complete list since I'm pretty sure that triggers still don't fire on events caused by cascading foreign key actions - and that doesn't appear to be mentioned there. The duck's still flying :-)	[reply]