1 |
I didnt think of case Item1, Item2, Item3. |
2 |
|
3 |
I thought of cases, for example, where i use Id field as TableName and |
4 |
IdInThatTable, where TableName shows, which table this IdInThatTable |
5 |
points and so on. I dont use, too, Item1/2/3 :) I just use tables |
6 |
sometimes in a more generalized form, where it's hard to say from |
7 |
table name or fields, what it is supposed to contain, as it contains |
8 |
different things in different cases -- therefore allowing me to make |
9 |
more functionality to general datastructures rather than writing |
10 |
specific tables with specific functions. Anyway, this is an example -- |
11 |
i just think that normalizing makes it so that there is 1 way to do |
12 |
things, but i like to rethink any specific case (and in some cases, |
13 |
normalized table just appears best to me, but not because it's |
14 |
normalized). Nothing more. Anyway, i think that this is not a topic to |
15 |
discuss in this list :) I think that db-app otimizations was best |
16 |
argument ever possible on side of normalization -- others are those, |
17 |
which will appear to me, too, but i havent much thought about which |
18 |
db's are optimized to which structures -- and this seems so that as |
19 |
normalization is in, any engines probably really are optimized for |
20 |
that. |
21 |
|
22 |
2006/3/14, Johannes Fahrenkrug <jfa@××××××.de>: |
23 |
> tvali wrote: |
24 |
> |
25 |
> >I will consider what you sayd about db app design. |
26 |
> > |
27 |
> >Anyway, i usually try to keep tables more dynamic and look at task at |
28 |
> >hand, trying to make tables specially for it. When i tested |
29 |
> >normalizing, i got about 60 tables where i had 5 without normalizing. |
30 |
> > |
31 |
> > |
32 |
> I'm not a Gentoo dev, but a programmer who deals with software and db |
33 |
> design issues every day. |
34 |
> Normalizing your data structures keeps them - and the apps that use them |
35 |
> - flexible. |
36 |
> |
37 |
> Of course a table with fields like "customernr, customername, item1, |
38 |
> item2, item3" is easier to create and smaller |
39 |
> than one table for the customers and one for items. But what if there's |
40 |
> a 4th and a 5th item? You have to change |
41 |
> your table and every place in your app that uses it (which should only |
42 |
> be one). |
43 |
> |
44 |
> I assume you're also not too fond of design patterns because some |
45 |
> require you to create 5 classes for something you could do with one ;-)... |
46 |
> |
47 |
> - Johannes. |
48 |
> |
49 |
> |
50 |
> -- |
51 |
> gentoo-portage-dev@g.o mailing list |
52 |
> |
53 |
> |
54 |
|
55 |
|
56 |
-- |
57 |
tvali |
58 |
(e-mail: "qtvali@×××××.com"; msn: "qtvali@×××××.com"; |
59 |
icq: "317-492-912") |
60 |
|
61 |
Ühe eesti internetifirma lehel kohtasin tsitaati: |
62 |
If you don't do it excellently, dont do it at all. Because if it's not |
63 |
excellent, it won't be profitable or fun, and if you're not in |
64 |
business for fun or profit, what the hell are you doing here? |
65 |
Robert Townsend |
66 |
|
67 |
-- |
68 |
gentoo-portage-dev@g.o mailing list |