I'm new to Java but not new to programming. I discovered this site through the awesome "Head First Java" book.
Here's my question.
I've got a sample Java program that loads fulltext records into a postgresql database using a prepared statement and a BufferedReader in a loop to read files in a directory and loads the contents of each file into the schema. That works. I now want to populate the other columns in the schema so need to modify the program. I'm wondering what a simple Java approach is.
Let's say my columns are col1, col2, col3, col4, and fulltext, where the col* fields are just strings. If I create a CSV file then can Java easily import it? Or, should I create a file that looks like this?
Basically, I'm trying to get oriented to how Java likes to see data in text files. And, I'd love to see examples of how Java parses data in text files.
Java itself doesn't have a preference for this. I would use CSV, because that's a more or less standard format which many other programs (for example, spreadsheet programs) also understand.
It's not hard to parse CSV files. A simple way would be to read a file line by line and then parse the line, by splitting it on commas (or whatever column separator you use in your CSV file). The thing that can make it slightly more complicated is if there might be commas in the data itself, which you would need to escape somehow.
If you don't want to write it yourself: There's nothing premade in the standard Java library to read CSV files, but there are small libraries which you can download to do this.
Stan Lederer wrote:Let's say my columns are col1, col2, col3, col4, and fulltext, where the col* fields are just strings. If I create a CSV file then can Java easily import it?
Shouldn't you be more worried about whether the database can import it? As Jesper says, many db's can already import CSV files directly.
Or, should I create a file that looks like this?...
My advice: NO. Stick to recognised formats.
However, my other question would be: why does your table include both columns AND 'fulltext'? It seems redundant to me.
You need to ask yourself a few questions:
1. What if somebody changes one of the columns in the resulting table? The column contents and the 'fulltext' will now be out of sync.
2. What if one of those columns is a date, or a currency amount? Doesn't it make more sense to make those column types reflect what it actually is? (eg, an SQL DATE). Strings make bad substitutes for other data types.
My 2 cents.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here