On Wednesday 16 January 2008 04:27:08 pm Ken Bloom wrote: > On Wed, 16 Jan 2008 13:33:06 -0800 > > Dylan Beaudette <[EMAIL PROTECTED]> wrote: > > On Tuesday 15 January 2008 09:57:57 pm Jeff Newmiller wrote: > > > Dylan Beaudette wrote: > > > > On Tuesday 15 January 2008, Henry House wrote: > > > >> On 2008-01-15, wrote Dylan Beaudette: > > > >> [...] > > > >> > > > >>> YES - this is how I would approach this problem if I were in a > > > >>> position to babysit their data. I have put together several LAPP > > > >>> (linux-apache-postgres-php) projects- but only for things I was > > > >>> directly working on. I was searching for some kind of compromise > > > >>> between doing it correctly (i.e. a database) and doing it less > > > >>> incorrectly via SVN or the like. > > > >> > > > >> Well the good thing about using SVN is that at least no data > > > >> will be lost once it is committed. So even if person A > > > >> overwrites person B's work, the data can be recovered (albeit > > > >> with manual intervention). And if this happens it just might > > > >> demonstrate the need for a proper RDBMS-base solution to those > > > >> in charge. > > > > > > > > Yeah... It looks like they will be resorting to their old system > > > > of personal communication mitigated data disaster prevention > > > > (PCMDDP).... When it crashes and burns I think that I will have > > > > them go with an SVN + CSV file setup. > > > > > > > > Thanks for all of the great ideas! > > > > > > > > Dylan > > > > > > I highly recommend using a real database with ODBC client access. > > > Microsoft Access is quite easy for Microsofties to get used to, > > > and has already been mentioned can serve as a front-end for > > > connecting to the shared data. OpenOffice can also present a > > > tabular user interface with no programming. No programming means > > > practically no maintenance on your part. They can use a query > > > builder to get subsets of the data, copy it into Excel, and analyze > > > it to their hearts content. Another advantage of this is that it > > > is easy to copy/paste large blocks of data around (including > > > appending their data to the table) which is not so easy with a web > > > interface. > > > > Jeff, > > > > Sounds like a great idea. Want to implement it as a donation? I am > > working with others who do not have the training or time to be > > interested in such things. I advocated something like this last year, > > but they went with the 'email a spreadsheet around' approach. > > I'm not convinced that you've actually played with the OpenOffice > Database idea yourself, becuase it's so easy to set up, and so similar > in interface to a spreadsheet, that you'd kick yourself for complaining > about not having training.
There is a reason for that- I haven't, yet. I just monkeyed around with it for a couple minutes and you are right- it does look pretty simple. I suppose that given some *free* time to implement, idiot-proof, and train staff this would work out ok. > > In short, start OpenOffice, click new database, set up the database > connection from the wizard. If you're going to do MySQL, then you may > want to install that first -- connecting shoudn't be terribly hard, > and I doubt installation is either. For now create an embedded > database, and just know that you can use OpenOffice to set up the > schema of a MySQL database when you decide that's the way to go. Yes- this looks nice. I wonder how hard it would be to get this working with PostgreSQL... and how this setup works with concurrent use... > Then hop on over to "Tables" and hit "Create table in design view" > Just fill in the names and types of the field, and save the table. Now, > if you double-click the table's name, it will look just like a > spreadsheet. (As long as your guys don't want any formulas in it.) It's > pretty simple, and takes less than 5 minutes to set up. > > To be fair, I couldn't copy/paste a range of data from spreadsheet > to database in OpenOffice (it wants to put it all in one field in one > row), but MS Access should be similarly simple to use, and may get rid > of this bug as well. > > --Ken I like the ideas. I reality these guys should be using a database, with several tables. They are accumulating data and pairs of sensor values - standards. It would be extremely useful, and a lot of fun to program, a data collection system where you could input data and standards- with everything tied together by common ids... This would allow both raw data and standards to be coherently stored in a highly structured format. Any compsci students looking for a project? thanks Ken, Dylan _______________________________________________ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech