> That's a red herring - the whole point of the
> discussion is MySQL's claim to be a _relational_
> database, which it isn't.
Glad *I* didn't claim that MySQL was an RDBMS.
Triggers and stored procedures provide increased performance in specific situations. Thses usually involve very few client conections (not really enterprise class apps). Replication and mirroring aside (which you would only need for back up and fault tolerance, if you designed right) there should be only *1* data store, however, there are multiple clients. By concentrating your logic in the data store you are creating a bottle-neck instead of distributing the load across clients. This is why triggers and stored procedures are generally bad (for large apps). If you can't understand this, then there is nothing that can be done for you.
> Your column flag work-around for row-level
> locking provides a textbook example of how to
> slow a database to a crawl. You need to read
> a good book on concurrency and deadlocks to
> know why you're scheme is disaster bound, e.g.
> (one of many) what happens when one of your
> clients crash after setting and before
> resetting your flag?
See above discussion. Distributing the load across *multiple* clients as opposed to a *single* data store REDUCES lag. As far as a client dying unexpectedly, see the original post, use a timestamp for the flag and use a timeout. If the lock's expired then tough shit for whomever set it.
"Let's say your company decides that the USPS just isn't good enough. The new policy is that all US customers get their shipments via UPS or FedEX. Suddenly all those "PO Box" addresses in the database are no longer valid."
My design practices:
User Interface (HTML, GTK, etc..)
Communications Layer (CGI, network, etc..)
Application Layer (Business Logic, etc..)
Data Store (DB, flat file, etc..)
This (a well designed system) solves the above problem as well as countless others that may pop up. I understand that time-to-market is important to a commercial entity, but there is a price to be paid for any decision made during the design process (such as limiting the design process). A good design isolates the application's logic from the data store and UI; And the UI from the application logic.
Databases have 2 simple requirements:
1) Reliably store data
2) Reliably retrieve data
Replication, transactions, row-level locking, stored procedures and triggers are NOT requirements of a database.
However, MySQL *DOES* have full transaction support through the use of Berkley DB tables.
A few good reasons not to use triggers and stored procedures are:
1) Performance
2) Portability
Application code should be kept in the application, not the data store (which is what a database is). Those of you who feel that MySQL is not a real DB do not know what a real DB is. Your views are tainted by Oracle marketing.
As far as row level locking goes; It can be easily implemented throught the use of a flag column in your tables. This can be used for passive or active locks. This flag could be:
I work for a small company that has mostly done contract programing. We are now moving towards a product building phase and have put together some thoughts on open source. As were are a for-profit organization we must charge for the stuff we produce. However, there has been an official management decision to make the full source to all of our [future] products (that we have licensing control over, i.e. not contract work) freely available at no charge (download from site) with no prior purchase of the product neccessary.
Although we may license some of our products as free-of-charge for personal use, or completely free-of-charge, or even GPL'd, the majority of our products will remain under a commercial Open Source license available for a reasonable fee. The gist of it being:
Our source code may be freely distributed as long as it remains unmodified. Community modifications to the source code must be distributed separately from our source distribution.
In order for community modifications to be included with our source distribution they must be submitted to, approved, and distributed by us. We do not pay for community contributions
We will never charge for any community modifications submitted to and distributed by us, but we retain the right to distribute them
Compilation of the source for investigative or educational purposes is acceptable; Use of compiled binaries without an appropriate license is not.
This sort of license still offers the benefits of Open Source while allowing us to remain in business.
As I said, this license is still "under development" and we as of yet have no products to apply it too but we still think its a good idea.
Slashdot Mirror
Triggers and stored procedures provide increased performance in specific situations. Thses usually involve very few client conections (not really enterprise class apps). Replication and mirroring aside (which you would only need for back up and fault tolerance, if you designed right) there should be only *1* data store, however, there are multiple clients. By concentrating your logic in the data store you are creating a bottle-neck instead of distributing the load across clients. This is why triggers and stored procedures are generally bad (for large apps). If you can't understand this, then there is nothing that can be done for you. See above discussion. Distributing the load across *multiple* clients as opposed to a *single* data store REDUCES lag. As far as a client dying unexpectedly, see the original post, use a timestamp for the flag and use a timeout. If the lock's expired then tough shit for whomever set it.
This (a well designed system) solves the above problem as well as countless others that may pop up. I understand that time-to-market is important to a commercial entity, but there is a price to be paid for any decision made during the design process (such as limiting the design process). A good design isolates the application's logic from the data store and UI; And the UI from the application logic.
Databases have 2 simple requirements:
1) Reliably store data
2) Reliably retrieve data
Replication, transactions, row-level locking, stored procedures and triggers are NOT requirements of a database.
However, MySQL *DOES* have full transaction support through the use of Berkley DB tables.
A few good reasons not to use triggers and stored procedures are:
1) Performance
2) Portability
Application code should be kept in the application, not the data store (which is what a database is). Those of you who feel that MySQL is not a real DB do not know what a real DB is. Your views are tainted by Oracle marketing.
As far as row level locking goes; It can be easily implemented throught the use of a flag column in your tables. This can be used for passive or active locks. This flag could be:
1) userID
2) incremented integer
3) time-out (DATETIME)
4) userID+time-out
Consider reading a products [current] documentation before you say what it can and cannot do.
-- (my apologies for this semi-rant and poor speling) --
The framework for our developing license is this (from http://www.ipninc.com/opensource/:
Although we may license some of our products as free-of-charge for personal use, or completely free-of-charge, or even GPL'd, the majority of our products will remain under a commercial Open Source license available for a reasonable fee. The gist of it being:
- Our source code may be freely distributed as long as it remains unmodified. Community modifications to the source code must be distributed separately from our source distribution.
- In order for community modifications to be included with our source distribution they must be submitted to, approved, and distributed by us. We do not pay for community contributions
- We will never charge for any community modifications submitted to and distributed by us, but we retain the right to distribute them
- Compilation of the source for investigative or educational purposes is acceptable; Use of compiled binaries without an appropriate license is not.
This sort of license still offers the benefits of Open Source while allowing us to remain in business.As I said, this license is still "under development" and we as of yet have no products to apply it too but we still think its a good idea.