For me the site still has a couple of shortcomings:
1. It doesn't detect your browser type and use a mobile stylesheet when appropriate.
2. Upvoting/downvoting comments should be implemented in AJAX so that you don't get a new page every time.
6 posts • joined 17 Apr 2014
As much as it pains me to defend the DfT I don't think what you're saying is accurate. A trial conversion of third rail to overhead from Southampton to Basingstoke has been discussed. If it goes ahead the costs of it will be used to estimate how much it would be to convert the rest of the network. I wouldn't get too concerned because it probably won't happen very soon, if at all.
However, it is not daft at all. 25 kV AC overhead is a superior and more modern system that allows more power to be delivered and speeds above 100 mph with less energy wasted as heat. It could be cheaper in the long run because it doesn't require massive rectifiers to convert AC to DC like a 750 V DC third rail system does. The route selected would provide a 25 kV electrified route all the way from Southampton to Sheffield, possibly further.
Having spent three months recently battling to get an iPhone unlocked on T-Mobile (EE) my advice is to buy your own unlocked device outright, then get a SIM for it separately and don't tie yourself into a long contract. Not only is it cheaper overall to do it this way, it's easy to get a PAK code if you want one and go elsewhere. It saves any futile rantings on an operator's Facebook page.
This article is clearly written by someone very enthusiastic about SQL Server, which is fine but when summarising new stuff that hasn’t been used in anger much a lot of important detail and caveats get lost.
A few specific comments:
MVCC has been implemented in Oracle for over a decade and so I don’t see how it’s a technique that’s only been enabled by storing data in memory instead of disk. Unless SQL Server’s implementation is different, it doesn’t eliminate locks: it just means that readers are not blocked by writers. Also the comment about blocking and locking being a major bane for DBAs is something that’s only caused significant pain for me when working with SQL Server. On Oracle, Informix and my limited experience of DB2 this is generally not the case. Others’ experience may vary of course.
The in-memory database sounds severely restricted and I can’t see how many existing applications would be suitable for a migration to it, even partly unless things like constraints don’t matter to you. In most organisations DBAs, at least production support DBAs, are unlikely to drive any change to this feature.
Column stores will always be better suited to warehouses. While having them in a primarily OLTP database can be advantageous, it is usually report-style queries that see the significant speed-ups.
Using SSD as a secondary buffer cache is nice, but many SANs effectively offer this already. Is this feature needed at the RDBMS level? The author is also in danger of giving the impression than in a typical OLTP system most reads go to disk (I am sure he must know this isn’t generally true). It is usually possible to get over 99% of disk reads from the database buffer cache.
About the author’s summary, all the database vendors are looking at what the others are doing and integrating similar features into their products. There isn’t a feature listed, save perhaps the secondary buffer cache, which is not available from another vendor today in some form or other.
Biting the hand that feeds IT © 1998–2021