Gentoo Archives: gentoo-portage-dev

From: tvali <qtvali@×××××.com>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] Few things, which imho would make portage better
Date: Tue, 14 Mar 2006 16:25:20
Message-Id: cea53e3c0603140824o5885c43al@mail.gmail.com
In Reply to: Re: [gentoo-portage-dev] Few things, which imho would make portage better by Johannes Fahrenkrug
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