Component Design Finals Summary
by the Design Review Board
TopCoder Members
Friday, May 5, 2006
Congratulations to Pops, the overall Design Competition winner! See below for a summary of how the Design Competition went...
First online finals round
by victor_lxd
The Relation component consists of data structures which hold objects, constraints associated with objects, and the relationship among objects. It also includes a relationally complete set of operations for manipulating those data structures, including project operation, restrict operation, union operation, difference operation, inner join operation, and outer join operation.
Design of the relation component is very challenging because competitors have to finish designing the component (which is like a mini-database system) within one week. The key challenge of the design is figuring out how to achieve time-efficiency and space-efficiency for the relationally complete set of operations. This component could be used in a data abstraction layer to contain data returned from SQL queries and to perform operations on that data. The data volume handled by this component could be huge. How to perform nested inner/outer join while achieving both time and space efficiency will definitely be the focus of the design. In addition, as we all know, handling null value in datebase system design is a tricky task, especially when outer join is involved. How to handle null value is another important design decision competitors have to make.
Second online finals round
by aksonov
The XSD2DDL component is a kind of transformer from XSD format to DDL. These formats are quite different, so the design for this component needs to be quite complex to meet all the requirements.
XSD2DDL was the most interesting component among final online components from the design point of view. There are different ways to implement this component and none of them is wrong -- event driven model, MVC model and even template-based approach -- and each method has its own strong parts.
The most difficult task was to create a really extensible framework which would allow the easy addition of various RDBMS DDL syntaxes. It was important to have the ability to reuse existing DDL transformation and implement only DDL syntax differences without rewriting the same parts (otherwise it would not be 'easily added database.')
To meet this requirement contestants had to separate XSD parsing logic and DDL generation as well as separting of various aspects of DDL generation -- table, column and constraint generation. Some solutions separated even different constraint types to allow changes to only some of them (like regexp constraint), but reuse other ones (like unique constraint syntax which is the same for most RDBMS).
Another challenging task was allowing support for new features like 'Table comments.' Contestants had to create extensible data structure representing transformed data and define interfaces to generate the appropriate DDL for added data. From the other side, the design needed to avoid becoming overcomplicated with complex API, or else users would not know how to accomplish the required tasks. Only the designer who was able to found the golden mean will win this exciting online round!
Third online finals round
by WishingBone
The DataView Decorator/Result Set Collection Decorator components require a read-only decoration of the underlying result set, which can be customized with extra data and behaviors. This seemingly compact design isn’t easy at all.
First, the decoration needs to be tailored with a hierarchy of entities, including the collection, the iterator, the result row and the metadata. Care should be executed to make these entities work consistently with the add-ons; and at the same time the solution should still take up some performance concerns. Second, the component needs to accommodate pluggable behaviors. It’s crucial that the behavior definition be powerful while easy to program against. Last, but not the least, is that the component should provide a clean API to work with data and behaviors associated on different levels. A solution satisfying these criteria is very likely to earn a decent score from the review board.
First onsite finals round
by victor_lxd
The appeals phase lasted 2 hours. In total, there were 135 appeals received, with almost half of them (67) accepted. Reviewers were overwhelmed by the large amount of appeals from competitors. Some appeals targeted mistakes made by the reviewers, while others brought up different interpretations of review guidelines. The appeal phase went smoothly. The result after appeal phase nearly remained the same as before appeal phase. nicka81 won the relation component design with a final score 94.52.
Second onsite finals round
by aksonov
As usual, the appeal phase contained two main types -- appeals about structural design issues (API, scope, extensibility) and apeals about presentation/documentation issues (algorithm description, poseidon documentation, demo).
Many appeals focused on the 'extensibility' section, where some designs were penalized for the issues described above - the designs don't allow the re-use of existing DDL elements for other RDBMS. They mostly were rejected because this extensibility feature is critical.
Third onsite finals round
by WishingBone
The onsite appeal phase got pretty intense and the review board was flooded with a total of 166 appeals, of which about 50 percent are successful. However the original ranks were not affected too much by the intensity. Pops secured first place via 12 successful appeals out of 16 -- an amazingly high success rate of 75%. On the other hand a few of the competitors submitted around 25 appeals each. Overall the submitters obtained an average raise of more than 7 points on each scorecard, which is probably going to be a new TCO record.
