3 ms·
The avoid ORDER BY is the main reason not to fall into per-cpu licensing (most commercial data engines). That's the licensing trap they make. Also it's the sam
by alecco 10y ago
The avoid ORDER BY is the main reason not to fall into per-cpu licensing (most commercial data engines). That's the licensing trap they make.
Also it's the same for other things requiring memory/cpu like JOIN and all that. You don't want to end up walking on eggshells.
- BrentOzar 10y ago> The avoid ORDER BY is the main reason not to fall into per-cpu licensing (most commercial data engines). That's the licensing trap they make. I used to agree with you, but in the cloud, all databases are essentially per-CPU licensing. It's just that instead of paying once up front, you pay by the hour. That's also why I love database administration as a long term career bet, too. Now, I can go performance tune someone's database queries, and they see an instant reduction in their monthly bill, thereby justifying the DBA cost. If I tune someone's on-premises licensed server, they don't get an instant rebate - the licensing and hardware is a sunk cost.
- alecco 10y agoSorry but it's not the same. When you use your own hardware you have to scale it to handle the peak usage times. This is often a small fraction of the day. I don't like putting databases in the cloud, but there you pay closer to actual usage instead of 24x7 at max capacity. BTW I was thinking in open-source options. Or commercial ones with a less draconian licensing (if there are any left).
- BrentOzar 10y ago> I don't like putting databases in the cloud, but there you pay closer to actual usage instead of 24x7 at max capacity. Bad news again - with Amazon RDS and Azure SQL DB, you pay a fee based on instance size, and you can't scale up/down instantly with demand. (You can scale automatically, but it takes quite a bit of work - you don't "pay actual usage."