| Title: | DEC Rdb against the World |
| Moderator: | HERON::GODFRIND |
| Created: | Fri Jun 12 1987 |
| Last Modified: | Thu Feb 23 1995 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1348 |
| Total number of notes: | 5438 |
Project: ---------- Fair sized project. 6 remote sites spread across 200 miles feeding a central system with very simple transactions. 2.1 million customer payments should be turned into 3.6 million transactions (credits & debits) per day. This must happen between 8:00 and 13:00 - giving a rate of 170 tps. System should be able to cope with up to 250 tps. 1.1 Gigabytes of data per day generated in a day file. The rest of the day is used to verify this information and load it into the master database (300 giga). 40 terabytes of history to be maintained on tape (not clear how). Situation: ---------- Sybase are already in the project. Their software has been used to write the customer maintenance software - so they have an advantage as incumbents. The group running the project have decided to commission TWO prototypes for the part mentioned above - one from Sybase, one from Digital. As the project is about $75 million (including all the hardware/printers/optical readers, infrastructure, other S/W etc.) they reckon that they can afford to put teams in competition and throw one of the solutions away. Things will follow roughly as follows. Starting in May, 4 months to build a prototype. Benchmarking will be in September. We can use anything that we like - hardware and software - provided that the products are commercialised by the start of 1994. They have a bias towards (open) VMS as the backend as they regard it as more proven in a commercial environment. Front end (6 districts) could be UNIX or VMS - they're interested in the best solution and not OS wars. They have a good working relationship with Digital and Sybase, however it is clear that they think that Sybase will win any competition. They are particularly impressed by its distributed capabilities - thinking that this will give Sybase a big advantage. I would like to know why! I've read notes 830,886, 1011 and 1024 - but time has moved on since then. Thanks for any information. Cheers Stephen Simpson
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1107.1 | You can solve around the problem | COOKIE::BERENSON | Lex mala, lex nulla | Mon Mar 16 1992 22:51 | 19 |
If all database activity is done on the back end, then SYBASE *may* have an advantage. It depends on if you can use ACMS and how the work of the transactions is partitioned. SYBASE's advantage would come from its ability to have large multi-statement procedures on the backend which are invoked with a single call from the client. This reduces client/server communications. Rdb will, if normal remote access is used, require more client/server communications. If ACMS is used to distribute the processing, you can essentially equal (or even exceed) the amount of work per request between the client and server. Then you just have to be careful to not move TOO MUCH work to the server or you won't make good use of the client's capabilities. There are also plans to eliminate this particular advantage that SYBASE has over Rdb. If you can't use the ACMS solution, then it may be worth talking to the Rdb Product Manager about futures in this area. Hal | |||||
| 1107.2 | NSDC::SIMPSON | Wed Mar 18 1992 08:32 | 7 | ||
Hal, Thanks for the hint about why Sybase may have an advantage. The physical design and product decision is up to me - so ACMS should fit in just fine (even if they decide on a UNIX front end). Steve | |||||