Re^2: storing some values (of an array) to a DB: how does Perl talk to MySQL?

hello Marshall,

many thanks for the reply. As allways - your ideas were very helpful and supportive!

Pursue your database learning as an independent thing from the web page scraping. Get each major piece working by itself before trying to integrate the whole thing together.

right - this is a very good idea!

i will follow your advices.

you tipps are great!

btw: i allready have some books here - among them the book, Programming the Perl DBI from Tim Bunce and by Alligator Descartes

i will read this and try to digg deeper into the interaction of Perl and MySQL

thx for advising these literature!!

some months ago, I have seen that you often try to take too big of a step at one time. Like going from "playing with bottle rockets in the backyard" to "let's fly to the moon"!

;-> right said! ;-) thx again...

have a great time!!

many greetings

Comment on Re^2: storing some values (of an array) to a DB: how does Perl talk to MySQL?

Replies are listed 'Best First'.
Re^3: storing some values (of an array) to a DB: how does Perl talk to MySQL? by Marshall (Canon) on Dec 21, 2010 at 01:54 UTC
btw: i allready have some books here - among them the book, Programming the Perl DBI from Tim Bunce and by Alligator Descartes That is too detailed to start with, get the "Learning SQL" book I recommended and start there. The first 4 chapters are very important and I have actually worked through all the examples just I recommended for you. I know for sure that it is good because I have done it myself. I added a post to this thread, please consider that idea as well. If you can get to the .csv format, importing this into the MySQL DB is like 1/2 page of code. Update: I decided to strike-thru the rest of this post. Not because it is "wrong", but rather because the detail doesn't matter at this point and I think it was confusing. I think the OP should start with a single table. That table should be a .CSV file. And let's leave it at that for the moment. In DB lingo, what is called "normalization" is a big thing. Instead of a string "Hessen" appearing as a field, this would be essentially a reference to another table that defines the spelling (user presentation of "Hessen"). This saves space and allows the name to be changed. Also allows Hesse and Hessen to be the same thing. The main idea is that everything is defined once. You don't need that - or at least not in any first step. ~~I think that a single table will do every thing that you need at the first step. This will be in "un-normalized" form. And that is fine.~~ In your application, the space doesn't matter. You may need a hash table conversion from say Bavaria => Bayern prior to putting that name in the DB, if so then just do it. No German is going to be confused by this mapping. Keep it simple and just use one term within your DB. In America: TX, Tex, Texas all mean the same thing in terms of postal codes. TX or Texas would be preferred over Tex, but believe me the post office would deliver the mail. I have a module that maps all sorts of state names into official postal codes. There are many thousands of aliases. Some knot-head will put "Texass" and that gets translated to "TX". I am confident that Germany has some standard for postal codes for the Bundeslaender. A very fast "look-up" table. Use that result in your DB.	[reply]

Replies are listed 'Best First'.

Re^3: storing some values (of an array) to a DB: how does Perl talk to MySQL?
by Marshall (Canon) on Dec 21, 2010 at 01:54 UTC

btw: i allready have some books here - among them the book, Programming the Perl DBI from Tim Bunce and by Alligator Descartes

That is too detailed to start with, get the "Learning SQL" book I recommended and start there. The first 4 chapters are very important and I have actually worked through all the examples just I recommended for you. I know for sure that it is good because I have done it myself.

I added a post to this thread, please consider that idea as well. If you can get to the .csv format, importing this into the MySQL DB is like 1/2 page of code.

Update: I decided to strike-thru the rest of this post. Not because it is "wrong", but rather because the detail doesn't matter at this point and I think it was confusing. I think the OP should start with a single table. That table should be a .CSV file. And let's leave it at that for the moment.

In DB lingo, what is called "normalization" is a big thing. Instead of a string "Hessen" appearing as a field, this would be essentially a reference to another table that defines the spelling (user presentation of "Hessen"). This saves space and allows the name to be changed. Also allows Hesse and Hessen to be the same thing. The main idea is that everything is defined once. You don't need that - or at least not in any first step.

~~I think that a single table will do every thing that you need at the first step. This will be in "un-normalized" form. And that is fine.~~

In your application, the space doesn't matter. You may need a hash table conversion from say Bavaria => Bayern prior to putting that name in the DB, if so then just do it. No German is going to be confused by this mapping.

Keep it simple and just use one term within your DB. In America: TX, Tex, Texas all mean the same thing in terms of postal codes. TX or Texas would be preferred over Tex, but believe me the post office would deliver the mail. I have a module that maps all sorts of state names into official postal codes. There are many thousands of aliases. Some knot-head will put "Texass" and that gets translated to "TX". I am confident that Germany has some standard for postal codes for the Bundeslaender. A very fast "look-up" table. Use that result in your DB.

[reply]