[vox-tech] collaborative data storage (of excel files)

[Dylan Beaudette]

On Wednesday 16 January 2008 04:27:08 pm Ken Bloom wrote:
> On Wed, 16 Jan 2008 13:33:06 -0800
>
> Dylan Beaudette <dylan.beaudette at gmail.com> 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