/[rserv]/doc/rserv-design.txt
This is repository of my old source code which isn't updated any more. Go to git.rot13.org for current projects!
ViewVC logotype

Contents of /doc/rserv-design.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (show annotations)
Sun Aug 17 21:00:31 2003 UTC (20 years, 8 months ago) by dpavlin
Branch: MAIN
CVS Tags: before_onlytables, before_multmaster, r_0_3, HEAD
File MIME type: text/plain
added design notes for version 0.3

1 RServ design considerations
2
3 This document will try to describe Rserv implementation details as well as I
4 (Dobrica Pavlinusic) can describe them, as well as provide some insight into
5 problems which occured during implementation of RServ 0.3 version (dubbed
6 "improved by community").
7
8 I would particulary like to thank Alen Lovrencic for interesting discussion
9 on database design and good lunch during that.
10
11
12 * How to find field (just one) which is unqiue identitifier for table?
13
14 Quick answer to this question is to use primary key. But, all databases "in
15 the wild" doesn't have primary keys defined.
16
17 How to find unique identifier for some row: find unique not null index for
18 that database (that is definition of primary key). Other solutions can
19 provide unique identifiers but only for currently available data.
20
21 We have to consider problem with associative tables (which have primary key
22 which is compound of foreign keys). One possible solution is to add
23 additional column which will be unique, not null index. Sequence comes to
24 mind, but can't be used because that column must be same in both databases
25 if we want to be sure that our data is consistent.
26
27 Examine uuid implementation.
28
29 Hashing might seem like solution, but it doesn't garantee unique mappings
30 between source data set (data in database) and newly created identifier
31 which is required.
32
33 If unique index not null doesn't exist we can provide different methods
34 which have complexity from n*nrattr (if we start with all fields and drop
35 one by one) or 2**nrattr (if we try every possible combination to find
36 minimal key, but exponential complexity prohibit us to do this).
37
38 ---
39
40 Consider do we need indexes on replication log tables. If replication is
41 done frequently, overhead of indexes might be considerable. Test this on
42 data and find breaking point.
43

  ViewVC Help
Powered by ViewVC 1.1.26