If you have a look at John's blog, you'll see that databases are the most commonly done out of all computer science projects. This is mainly because it is easyish to do. I'm following the beaten track if you've read my previous post, but I need to focus more on the actual problem.
We as a family have managed to amass a massive amount of books and music cds. It would be better if we could all see what books we have as in the past we have managed to get repeats of books we already have.
My customer is going to be my Dad, who wants to be able to search through his collection of books and musical cd's by genre, author and more. Thus, I need to be able to add, remove, modify and filter data for the database. A possible feature that could be added is a link to Amazon search, to bring up the data automatically when the title is used.
Showing posts with label planning. Show all posts
Showing posts with label planning. Show all posts
Wednesday, 26 August 2009
Monday, 24 August 2009
Look Ma, I'm on the internets!
I've dabbled with blogs in the past (eg Xanga) but now actually writing this thing matters. My computer science dossier has to be documented constantly from the birth of the idea to its eventual conception. Currently, I'm planning a database with a twist - it pulls data from Amazon and autocompletes fields for you. It'll be used for albums and books with the possibility of expansion.
As per usual, I've jumped the gun and thought of a neat program that I could write which includes some of what I've learnt in the past. I have some old code that basically follows this structure so the main work is adapting/updating it.
The problem is that my dad has too many CD's and books to sort through and wants a unified way of working out the size of his collection (Eg Database).
I have some idea of how it should work as I typed out some notes beforehand:
Storing Data
Using a text file with strings appended with a unicode character because of string length flexibility. The disadvantages of doing this is that it will be slow for read and write (because it needs to process the lines and then the strings) but the string length justifies this. This is because I don't acutally know how long the titles or other information can get, so its best to future proof the database. Two text files will be used, one for books and the other for music - speeds up the data processing + reduces excess fields. This works out because if it was in one, there would need to be a TYPE field, to differentiate between books and CD's. Data will be written, not appended to make it easier to remove data when requested. This is because there are two main ways to write data, the entire file or at the end. Writing the entire file avoids lots of problems so it is the better solution. No images will be used, the reason for this is because of base64 encoding. Base 64 is when you convert a file to text but it may include the end character that splits the data apart. This will cause errors so its easier to nip it in the bud by not having it at all.
Data Input
This will be handeled by simply entering the data in the database. A possible feature that will hopefully be implemented is pulling data from amazon .com for the author, date, genre and other data. For multiple results - if less than ten results and show the data returned and let the user pick the correct one. If one result returned only, use that data. If more than ten, ask the user to specify their request. When the data is read from the text file it is placed into an arraylist. Doing this means that removing entries will remove the current selection from the arraylist. These modifications will be saved when the entire list is written to disk. Adding new entries will follow a similar process in which the arraylist expands to fit the new data.
User Interface
I will use AWT for the user interface, with text boxes for the input (everything can be modified) with buttons to accept confirmation. A feature that needs to be implemented is searching/filtering and thus will require a textbox to do so.
Thats basically what I've decided for this project in a big nutshell.
As per usual, I've jumped the gun and thought of a neat program that I could write which includes some of what I've learnt in the past. I have some old code that basically follows this structure so the main work is adapting/updating it.
The problem is that my dad has too many CD's and books to sort through and wants a unified way of working out the size of his collection (Eg Database).
I have some idea of how it should work as I typed out some notes beforehand:
Storing Data
Using a text file with strings appended with a unicode character because of string length flexibility. The disadvantages of doing this is that it will be slow for read and write (because it needs to process the lines and then the strings) but the string length justifies this. This is because I don't acutally know how long the titles or other information can get, so its best to future proof the database. Two text files will be used, one for books and the other for music - speeds up the data processing + reduces excess fields. This works out because if it was in one, there would need to be a TYPE field, to differentiate between books and CD's. Data will be written, not appended to make it easier to remove data when requested. This is because there are two main ways to write data, the entire file or at the end. Writing the entire file avoids lots of problems so it is the better solution. No images will be used, the reason for this is because of base64 encoding. Base 64 is when you convert a file to text but it may include the end character that splits the data apart. This will cause errors so its easier to nip it in the bud by not having it at all.
Data Input
This will be handeled by simply entering the data in the database. A possible feature that will hopefully be implemented is pulling data from amazon .com for the author, date, genre and other data. For multiple results - if less than ten results and show the data returned and let the user pick the correct one. If one result returned only, use that data. If more than ten, ask the user to specify their request. When the data is read from the text file it is placed into an arraylist. Doing this means that removing entries will remove the current selection from the arraylist. These modifications will be saved when the entire list is written to disk. Adding new entries will follow a similar process in which the arraylist expands to fit the new data.
User Interface
I will use AWT for the user interface, with text boxes for the input (everything can be modified) with buttons to accept confirmation. A feature that needs to be implemented is searching/filtering and thus will require a textbox to do so.
Thats basically what I've decided for this project in a big nutshell.
Subscribe to:
Posts (Atom)
