Home Projects Jobs Clientele Contact


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UU: User state

C++ module shouldn't have it's own copy of data, especially - data relations. Instead, it assumes this to be implemented in DB. Methods in C++ classes, in that case, simply call stored procedures.
For instance, we need to add a relation between a student and a problem. We should have a stored proc like student_assign_problem that does the job and reports the result. Another stored proc should report the list of problems assign to student.

- the business logic is concentrated in one place
- maximum possible performance, if we are not doing high-level math
- data processing in SQL is pretty simple
- bugs in stored procs are easier to fix (we just replace a proc in real time)
- in general case (didn't check enough with Postgres yet), SQL server controls the DML in stored procs, preventing some runtime errors
- SQL languages we can use require C-style programming
- debugging stored procs is more difficult than C/C++ code

The opposite implementation, when we have the logic implemented in C++, basically treats SQL server as dBase, having a data copy on the client and doing most of the processing there. That approach is acceptable when a few people are using a database. With the grow of user number, it leads to the slow down of the database.
- the code may be taken to pretty high abstraction level, encapsulating everything inside the classes
- easy to debug data processing
- the language (C/C++) is a sweety
- processing data involves a data copy on the client, therefore a round trip read-change-write - creates an extra steps in processing (performance issues)
- data modifications can be made from different places. Often (not necessary true for us), people untie the database security and integrity constraints to have more possibilities for data modification - leads to broken data integrity and poor performance
- fixing bugs in logic requires recompilation the C/C++ program and shipping it to customer. That is more difficult than patching a stored proc

There are some pros and cons I'm probably missing.

It's possible to use a combined approach. In my experience, it combines the problems of both prior approaches and advantages of none :(

2006/9/14, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
Can you elaborate?

Alexey Parshin wrote:
> In ideal case, C++ should not worry about implementation details ..
> 2006/9/13, Ilya A. Volynets-Evenbakh < ilya@total-knowledge.com
> <mailto:ilya@total-knowledge.com>>:
>     Of course it's going to be in database. I'm wondering about C++
>     side of things. Although I'm leaning towards having it in there as
>     well.
> <http://www.sptk.net>

Ilya A. Volynets-Evenbakh
Total Knowledge. CTO

Alexey Parshin,

Authoright © Total Knowledge: 2001-2008