[mysql-dde] Re: Fw: P/F/U Keys in LDD

  • From: "Fabricio Mota" <fabricio.oliveira@xxxxxxxxxxxxxxxx>
  • To: <mysql-dde@xxxxxxxxxxxxx>
  • Date: Tue, 20 Dec 2005 15:18:24 -0200

Lets pontuate these items (reliability, integrity, etc.) for each solution 
in the following set of values:

PERFECT - we get a value that is never necessary or possible to get better 
results than it.

BEST - we get a value that, despite not to be perfect the model, it is known 
not to be possible exist another value better than it.

GOOD - Despite it not to be the best solution possible in terms of this 
measure, the solution is most than sufficiently satisfatory.

SATISFATORY - The solution just solves the problem in this aspect.

INSATISFATORY - The solution does not solve the problem sufficiently, 
despite a big effort in this intention.

BAD - The solution keeps distant of the necessary value to satisfy the item.

WORST - The solution is the worst solution of all.

DAMAGED - The solution is completelly inappropriate to the model.

----- Original Message ----- 
From: "Fabricio Mota" <fabricio.oliveira@xxxxxxxxxxxxxxxx>
To: <mysql-dde@xxxxxxxxxxxxx>
Sent: Tuesday, December 20, 2005 2:53 PM
Subject: Re: [mysql-dde] Re: Fw: P/F/U Keys in LDD

> Maybe it is important we also get clear what is our objective with these 
> proposals.
> Our objective is, during insert/update/delete commands:
> minimize:
> - internal communication occurrences (internal requests between servers);
> - amount of auxiliar data (data used to maintain the DDE internal 
> structures, such as indexes, statistic tables, etc);
> - response time (for client requests);
> and maximize:
> - consistence (state that may considered safe and coherent, such as GI 
> always correctly replied among all servers);
> - integrity (user data will correspond to what he specified to be);
> - reliability (continuity of initialized operations, although in presence 
> of faults);
> - availability (ability to provide service, although in presence of 
> faults);
> - Scalability (keep the problems, assigned to number of servers of 
> system - such as time response, data size, etc - growing with a rate 
> compatible with system growing).
> - Transparence (keep the user have the feeling of to access a DDE cluster 
> quite as he is accessing a centralized server instance, avoiding, the most 
> as we can, to force user to take modifications to their applications and 
> database structures intending to solve internal DDE problems Ex.: force 
> user to include LOCAL column in all their unique keys, etc.).
> I just don't know what these topics are prioritary.
> What is the ideal solution:
> - no internal communication ocurrences;
> - no auxiliar data being needed;
> - immediate response time;
> - every structures consistent with all servers all the time;
> - user data will never be violated but only by his desire;
> - Every operation is always correctly finished still in presence of 
> faults;
> - Every service is available still in presence of faults);
> - the measures assigned to problems growns, at most, proportionally with 
> the growing of number of servers.
> - The user will never need to perform any undesired change to his commands 
> or structures to satisfy to DDE internal conditions.
> I think we already know the ideal situation is impossible! Now, lets know 
> how we will handle these values to perform the otimal solution!
> FM 

MySql-DDE discussion list

Other related posts: