It doesn't matter that the handoff is a mess because the mess never escalates to the point where it impacts the executive layer. The decision makers just beat on middle management and the new group to "make it happen". And it must work in the end, because if these sort of takeovers, which we know are an absolute mess, regularly resulted in any sort of serious negative business impact then I doubt they would be happening.
Average vehicle lasting 500k? Door lock motor outlasting owner? There is clearly some disconnect between engineering and manufacturing, or you guys forgot that the lock mechanism consists of more than just the motor and one of those other parts lasts about 4 years.
If you write a good foundation of libraries and classes you'll need a hack like APC to get any decent execution speed. It also sucks at memory utilization. Everyone likes to link to that "fractal of bad design" article, but it's pretty much just a bunch of whining. Here's a real article that just plain hurts, it has to do with PHP's memory allocation: https://nikic.github.io/2011/1...
Seriously? You think a clustered, 2 site license only runs $100K? Why are you even responding when you clearly have no idea what the pricing is. I assure you, it's NOT a drop in the bucket. Your pricing for the application side is equally clueless, except in the other direction.
One thing very relevant for discussion, that I didn't see mentioned here, is how connections are handled across the different RDBMS. PG still uses one process per connection. This can make its memory utilization grow substantially under high connection counts. Oracle and Mysql don't suffer from this issue.
Just the wording "a DB license" leads me to believe your exposure is with smaller companies and smaller datasets. Have you ever priced a single 32 core Oracle installation with the data warehousing option enabled? If it's a business of any size, you'll need to cluster for reliability, so multiply that single license out. And if it's a publicly traded company, you'll probably need an offsite standby cluster. Even though it sits there and does nothing 24/7, the licensing fee for the standby cluster will be the exact same price as if it was the primary. Also, don't forget dev and testing environments, those aren't free.
Not every large company is a high-margin high tech company. The retail sector, for example, has mountains of data and relatively low margins. DB license expense can be a big concern.
Can you read? I said "the ease in application of DDL changes", not that the application was applying DDL. In other words, when our DBA applied changes under Oracle, packages would be invalidated and all users had to exit the application. This issue doesn't exist under PG. You're an idiot, BTW.
Yes, DDL application is transactional. The company I work for went from Oracle to PG last year. The ease in application of DDL changes was a huge benefit that we didn't originally anticipate.
You nailed it. The AC's idea that all data access is performed via a single application is naive. There are cases where the only common interface point between applications is the database.
It's not cheap at all once you get into even just medium-scale usage. If you have a situation where you are starting out small but plan to grow, you need to really consider whether it's wise to go with a commercial RDMBS, because the pricing does get nasty when you get to the point of needing clusters, high core counts, and standby sites.
You are right, I am failing to adequately communicate what I am saying. That a transaction can be retried is a byproduct of the atomicity requirement that a transaction fills. Retrying a transaction, because there is an ongoing problem with the database system dropping connections, is a sloppy hack.
You said that the point of a transaction is to enable the ability to retry it. I said that was not the point. I don't see how we are saying the same thing.
That isn't the point of a transaction _at all_. The point is to ensure that all of the operations contained in the transaction block are atomic - they either all happen or none of them happen.
You can "handle" a dropped connection, but if you're in a transaction in the middle of updating data, it's probably not going to be transparent to the user.
You're exactly right. I have serveral old microwave cookbooks and they demonstrate using foil to cover small sections of meat and poultry to keep it from becoming overcooked.
>> Searching for records first goes to the "safe" side. If no records found use legacy system....as if the system consists of a single query, so the solution is simply to scan the new system and then the old system. Versus the reality of ten bazillion queries and thousands of database tables.
You do understand that the number of titles currently available via (legal) streaming is far, far less than the number of titles available via shipped plastic?
Slashdot Mirror
It doesn't matter that the handoff is a mess because the mess never escalates to the point where it impacts the executive layer. The decision makers just beat on middle management and the new group to "make it happen". And it must work in the end, because if these sort of takeovers, which we know are an absolute mess, regularly resulted in any sort of serious negative business impact then I doubt they would be happening.
An Indian friend was telling me that Indians are doing this en-masse to get jobs. They are also substituting for each other in video interviews.
Average vehicle lasting 500k? Door lock motor outlasting owner? There is clearly some disconnect between engineering and manufacturing, or you guys forgot that the lock mechanism consists of more than just the motor and one of those other parts lasts about 4 years.
My father is an electrician and that industry is being swamped with central and south american labor.
Damn, snagged!
If you write a good foundation of libraries and classes you'll need a hack like APC to get any decent execution speed. It also sucks at memory utilization. Everyone likes to link to that "fractal of bad design" article, but it's pretty much just a bunch of whining. Here's a real article that just plain hurts, it has to do with PHP's memory allocation: https://nikic.github.io/2011/1...
Seriously? You think a clustered, 2 site license only runs $100K? Why are you even responding when you clearly have no idea what the pricing is. I assure you, it's NOT a drop in the bucket. Your pricing for the application side is equally clueless, except in the other direction.
One thing very relevant for discussion, that I didn't see mentioned here, is how connections are handled across the different RDBMS. PG still uses one process per connection. This can make its memory utilization grow substantially under high connection counts. Oracle and Mysql don't suffer from this issue.
Just the wording "a DB license" leads me to believe your exposure is with smaller companies and smaller datasets. Have you ever priced a single 32 core Oracle installation with the data warehousing option enabled? If it's a business of any size, you'll need to cluster for reliability, so multiply that single license out. And if it's a publicly traded company, you'll probably need an offsite standby cluster. Even though it sits there and does nothing 24/7, the licensing fee for the standby cluster will be the exact same price as if it was the primary. Also, don't forget dev and testing environments, those aren't free.
Not every large company is a high-margin high tech company. The retail sector, for example, has mountains of data and relatively low margins. DB license expense can be a big concern.
Can you read? I said "the ease in application of DDL changes", not that the application was applying DDL. In other words, when our DBA applied changes under Oracle, packages would be invalidated and all users had to exit the application. This issue doesn't exist under PG. You're an idiot, BTW.
Yes, DDL application is transactional. The company I work for went from Oracle to PG last year. The ease in application of DDL changes was a huge benefit that we didn't originally anticipate.
You nailed it. The AC's idea that all data access is performed via a single application is naive. There are cases where the only common interface point between applications is the database.
It's not cheap at all once you get into even just medium-scale usage. If you have a situation where you are starting out small but plan to grow, you need to really consider whether it's wise to go with a commercial RDMBS, because the pricing does get nasty when you get to the point of needing clusters, high core counts, and standby sites.
I can second this, I've used Hover for over 10 years, from back when Tucows first offered OpenSRS.
It was a joke, have you ever looked at the "food" available at a sporting event?
To carry forward from the parent, do you think that a hunter/gatherer could imagine that someone would pay to eat the food at a basketball game?
You're aware that the OS was named "Windows" for a reason, right? And that you can't install the OS separate from the UI?
You are right, I am failing to adequately communicate what I am saying. That a transaction can be retried is a byproduct of the atomicity requirement that a transaction fills. Retrying a transaction, because there is an ongoing problem with the database system dropping connections, is a sloppy hack.
You said that the point of a transaction is to enable the ability to retry it. I said that was not the point. I don't see how we are saying the same thing.
That isn't the point of a transaction _at all_. The point is to ensure that all of the operations contained in the transaction block are atomic - they either all happen or none of them happen.
You can "handle" a dropped connection, but if you're in a transaction in the middle of updating data, it's probably not going to be transparent to the user.
-E
You're exactly right. I have serveral old microwave cookbooks and they demonstrate using foil to cover small sections of meat and poultry to keep it from becoming overcooked.
I love this:
>> Searching for records first goes to the "safe" side. If no records found use legacy system. ...as if the system consists of a single query, so the solution is simply to scan the new system and then the old system. Versus the reality of ten bazillion queries and thousands of database tables.
You do understand that the number of titles currently available via (legal) streaming is far, far less than the number of titles available via shipped plastic?
I'm sure I saw at least three dozen other commercials last night, anyone want to post an article about those?