Wikipedia:Articles for deletion/KDB (database)


 * The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review).  No further edits should be made to this page.  

The result was no consencus to delete, aka merge, also known as "keep" in some states. - 152.91.9.144 06:02, 17 November 2006 (UTC)

KDB (database)


Non-notable, proprietary product, little if any support from third party developers. Topic should be covered by non-company-specific technology page such as Event Stream Processing, etc. Ronnotel 17:12, 6 November 2006 (UTC)
 * Delete Article does not state why this particular software is notable. Reliable sourcing wouldn't hurt either. -- moe.  RON   Let's talk  01:27, 8 November 2006 (UTC)
 * Do not Delete A few responses
 * KDB is notable for its wide spread use in the financial industry.
 * KDB is the most common solution for implementing a ticker plant, an application that stores trade and quote data from an exchange.
 * KDB's performance when handling large amounts of financial data is orders of magnitude better than a standard relational database such as Oracle or SQL Server
 * The fact that KDB is proprietary is not a reason for deletion, Wikipedia contains numerous articles on proprietary products, in particular SQL Server, Sybase, DB2 and Oracle.
 * The fact that KDB lacks third party support is not particularly relevant given it's dominance in its niche.
 * While it has some of the same functionality, KDB is not a Stream Processing Engine (SPE). An SPE works by querying streaming data as it arrives without the need to first store the data; KDB first stores streaming data in an in-memory database for it executes queries.

The entry could be improved and certainly it is lacking references. It might make sense to merge this entry with the one on K (programming language). The K and KDB are tightly linked: KDB is developed in K and K itself is little used outside of KDB applications.

I do use both K and KDB and I am a fan of both, but I have no association with either Kx Systems or First Derivatives. Some of the points mentioned above might be difficult to document and I wouldn't include them in the actual entry. They are nonetheless true; I think anyone in the financial industry who deals with trade and quote data would find them uncontroversial. -- Abcarter 18:47, 10 November 2006 (UTC)
 *  Relisted to generate a more thorough discussion so that consensus may be reached  Please add new discussions below this notice. Thanks, Avi 22:57, 12 November 2006 (UTC)


 * Due to lack of comments, I strongly encourage Abcarter to go ahead and boldly merge as proposed. If anyone objects to your solution, you'll know soon enough.  ;-)   Un  focused  07:42, 15 November 2006 (UTC)
 * The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.