Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Ashoke S.

dblp:166/8356 · DBLP profile ↗
← Back
1ranked-venue papers
1as first author
0since 2021 · last 2015
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Databases, data management, data science and information retrieval · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
1 paper
Software testing · 100%
Databases, data mining, and information retrieval
1 paper
Query processing and optimization · 100%

Topics — the 2 heaviest of 2, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Software testing › database testing
database system testing
0.212015
CODD: A Dataless Approach to Big Data Testing · Proc. VLDB Endow. 2015
Query processing and optimization
query optimization
0.112015
CODD: A Dataless Approach to Big Data Testing · Proc. VLDB Endow. 2015

Methods — techniques the papers use, named apart from their topics

query optimizer behavior evaluation · 0.4
YearPublicationVenuePosition
2015 CODD: A Dataless Approach to Big Data Testing
abstract
The construction and development of the so-called Big Data systems has occupied centerstage in the data management community in recent years. However, there has been comparatively little attention paid to the testing of such systems, an essential pre-requisite for successful deployment. This is surprising given that traditional testing techniques, which typically involve construction of representative databases and regression query suites, are completely impractical at Big Data scale -- simply due to the time and space overheads involved in their execution. For instance, consider the situation where a database engineer wishes to evaluate the query optimizer's behavior on a futuristic Big Data setup featuring "yottabyte" (10 24 bytes) sized relational tables. Obviously, just generating this data, let alone storing it, is practically infeasible even on the best of systems.
Ashoke S., Jayant R. Haritsa
Proc. VLDB Endow.1