 | Computing Unassessed | |||||||||
| ||||||||||
Merger proposal
Original nominator didn't bother to begin a discussion. As for me, I haven't any clear opinion on this merge. --4th-otaku (talk)
My particular opinion on this is that we dont merge these two because they are far too broad in of themselves to be merged, final vote, no. - Joel Wyman Junior — Preceding unsigned comment added by 67.5.252.3 (talk) 23:26, 5 June 2014 (UTC)
- Those are two different subjects altogether
Regards, Tshuva (talk) 11:34, 23 June 2014 (UTC)
- As it stands, this article can't stay on Wikipedia anyway; it's written like an essay trying to sell you some products, not an informative encyclopedia article. I don't know if there is anything salvageable here, but merging it into another article is one way. Deleting is another way. -- intgr [talk] 14:56, 24 June 2014 (UTC)
This topic is increasingly important because most modern RDBMS support in-memory database functions and users need to understand when and how to use and tune these features. In-memory databases are distinct from in-memory processing by being transactional, by being durable (through durable transaction logs), and by supporting the usual DBMS features such as query languages. Falling DRAM prices have driven major improvements in the cost-effectiveness of in-memory database technologies, and they are now commonly mainstream. MySQL and Oracle have long supported this, and with the 2014 release Microsoft SQL Server also supports it. — Preceding unsigned comment added by 72.93.83.117 (talk) 14:48, 2 November 2014 (UTC)
———
These topics have little in common. IMDB is a large, established application ___domain. In-memory processing is just a grab bag of generic techniques.
- Micron: 3D XPoint In IMDB — 30 August 2015
Credit Suisse made the assertion that around 1.3 million - 1.4 million servers were running Oracle databases last year. Pitzer suggests a 2.5% penetration with 32 TB of DRAM would be a good estimate of the demand for DRAM created by IMDB.
This article is a stock pump, so apply salt in the metric prefix of your choice, but it's clear enough that this is a big, established market segment.
This discussion hasn't really gone anywhere and the proposer is MIA, so I'm removing the merge proposal from the top of the article page. — MaxEnt 18:58, 11 September 2015 (UTC)
Rewrite
From a technical standpoint this article has numerous issues. The article implies that by keeping all data in-memory no indexing is needed; this is incorrect for larger datasets. The reason for this is that a task's time complexity remains constant even if the underlying hardware (hard disk to RAM in the article) changes. In addition, the article implies that traditional databases hit disk for all queries and do not, e.g. cache data and indices in RAM. Additionally the article states that a traditional DB can only do one task (a write, a query, a view, etc.) at a time; this is not true. There are many other issues as well along with contradictions from paragraph to paragraph. Input from a DBA would be ideal but my opinion as a software architect/engineer is that the article should either be completely rewritten (preferably by a DBA) or deleted. — Alex Hajnal (talk) 07:02, 25 November 2015 (UTC)
- @AlexHajnal: Agreed. Until the rewrite happens, I think WP:STUBIFY is appropriate. -- intgr [talk] 08:23, 25 November 2015 (UTC)
- Agreed. — Dsimic (talk | contribs) 08:26, 25 November 2015 (UTC)