On Mon, 2002-02-25 at 10:43, Russell Hires wrote:
> Hey everyone,
>
> I've got a couple of projects going (several at work, one at home) that deal
> with using Databases. I'm finding that it's a big subject, and I know so
> little. Does anyone have any recommendations on what to look at (on the web,
> preferably) about dealing with design issues and such? I know that there are
> such places as mysql.com and postgresql.org that have documentation, and then
> there's doing google searches, but I'm hoping that personal experience and
> recommedations will be more helpful.
>
> I also know that there's at least a couple of people here that have database
> experience (ahem...Paul and Derrick :-)...
Yes? Hello? Is this thing on? :)
IMO, database design is something that's not particularly easy to
"learn" - it's not difficult either; you just have to do it for a while
and see what works. It's a lot like programming, but more
mysterious... There are many ways you can build the same database
structure, and chances are, many of them will be "correct" in terms of
the database actually working as expected.
One of the problems is that each database vendor tends to have their own
subset of SQL and vendor-specific reserved words. So it's hard to learn
something that works universally without learning all the differences,
which mostly comes from experience.
I think the most important thing is to learn how to normalize a
database, ah, err, but also that there is such a thing as "too
normalized."
And of course whatever you learn, remember that there are exceptions to
every rule...
Something I'm rather surprised isn't more common knowledge (it was
excplicitly taught in the database design class I took from Oracle)
that's worth knowing are "join tables" - although that's not how they
were taugh to me and I don't remember the terminology. If you need to
create a join between two tables, but you don't know beforehand how many
columns you might have to join - an example is you have a list of
products and a list of vendors, a product might come from multiple
vendors, but you don't know beforehand how many, so it doesn't make
sense to make "vendor1, vendor2, vendor3, etc" columns in the product
table because you won't know how many to make and it's bad practice to
pick an arbitrary number in case you go over - make a third table that
will join the two. So in our example, we have "Vendor" which has a
vendorID and "Product" which has a ProductID, and we have something like
"ProdVend" that has a column for both VendorID and ProductID. When you
need to know what Vendors carry a particular product, you get the
appropriate ProductID from the Product table and SELECT on that
ProductID from the ProdVend table to get the list of VendorIDs of the
Vendors that carry the product.
It takes longer to explain than to actually do it.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
print+x"C*",@a}';s/x/pack+/g;eval
usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
| extract_mpeg2 | mpeg2dec -
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
http://www.eff.org/ http://www.anti-dmca.org/
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 16:42:11 EDT