MYSQL form woes
August 20, 2007 5:42 PM Subscribe
MYSQL question: I want to develop simple input form for our internal office MYSQL. We need to attach files to our product information. I'm using OO, but it doesn't deal with BLOBs what other software could I use to create forms to our database?
The OO base actually does a decent job in letting me access our MYSQL, but now we need to attach a series of PDF files to entries. OO doesn't do this in a normal way, and blob type fields are not accessible via the form designer.
I don't want people messing with the database tables directly, but would really prefer to create a from input and display. I'm not a programmer, so I need to find something that will let me do this in a GUI. Any suggestions?
I'm using XP, and would prefer platform independent software.
The OO base actually does a decent job in letting me access our MYSQL, but now we need to attach a series of PDF files to entries. OO doesn't do this in a normal way, and blob type fields are not accessible via the form designer.
I don't want people messing with the database tables directly, but would really prefer to create a from input and display. I'm not a programmer, so I need to find something that will let me do this in a GUI. Any suggestions?
I'm using XP, and would prefer platform independent software.
Is it possible to not store the PDFs in blob fields? Maybe you could somehow store the path to the files? That might be better, and that way you have the PDFs in their normal file format so you can extract them outside of the context of the database.
But maybe I'm not understanding what you're trying to do.
posted by Deathalicious at 7:01 PM on August 20, 2007
But maybe I'm not understanding what you're trying to do.
posted by Deathalicious at 7:01 PM on August 20, 2007
Assuming you're not looking to do full-text search on the PDFs, Deathalicious's answer is probably the best thing to do. Store a row of pdf "meta-data" per row in some table, and have the pdf filename be attribute data on that row. To ensure that you don't have name collisions, use the row's synthetic key to generate all or part of the file name, e.g., full_file_name = pdf_directory/row_id_original_filename.
(Even if you are full-text searching, Deathalicious's is the way to go; you'd probably want to pre-process the pdfs once to get to text, store the pdfs on the file system, and the raw text in the database. This is somewhat complicated, and probably beyond what you want to do.)
posted by orthogonality at 10:43 PM on August 20, 2007
(Even if you are full-text searching, Deathalicious's is the way to go; you'd probably want to pre-process the pdfs once to get to text, store the pdfs on the file system, and the raw text in the database. This is somewhat complicated, and probably beyond what you want to do.)
posted by orthogonality at 10:43 PM on August 20, 2007
Amen to Deathalicious & orthogonality. Your already golden if your original row has an auto_increment column. And mysql's text search won't really work on pdfs. And external files are better for scalability too since you can serve them on another machine, give them seperate squiding, etc.
posted by jeffburdges at 2:00 AM on August 21, 2007
posted by jeffburdges at 2:00 AM on August 21, 2007
Response by poster: OO - yes, OpenOffice.
Hmm, that could work with filenames in the database and link externally. I don't need to search the files, but each database entry needs to have a list of files attached to it. Question is how to make it work in OO.
posted by Yavsy at 9:42 AM on August 21, 2007
Hmm, that could work with filenames in the database and link externally. I don't need to search the files, but each database entry needs to have a list of files attached to it. Question is how to make it work in OO.
posted by Yavsy at 9:42 AM on August 21, 2007
« Older Gimme filthy backroom post-industrial electro... | Help me be a responsible but care-free computer... Newer »
This thread is closed to new comments.
posted by the jam at 5:54 PM on August 20, 2007