Another major blow for the Seahorse Trust i Studland

When this furore started I had exchanges with NGM and up to that point his main activity was collating reported observations of seahorses from volunteers. The data was at that point the centerpiece of his website and justification for his existence.

However as soon as he got involved in Studland and the need to justify the statements about it being a major habitat and breeding grounds became his focal point the population data disappeared. Not surprisingly as it was inconsistent with his new claims.

Typical behaviour of the self proclaimed expert toward any evidence that does not support their position.
 
I guess the point I was trying to make but didn't make it very clearly us that in a properly written research database, there a little bit of the programme that sits there and records when each data entry was entered, by whom and when and if it has ever been edited. Easy enough to do on a well written Access database, never heard of it on an Excel one. However, I willing to bet a fair bit of cash that there's no such protection on the Seahorse Trust database, if it in fact exists.
 
I guess the point I was trying to make but didn't make it very clearly us that in a properly written research database, there a little bit of the programme that sits there and records when each data entry was entered, by whom and when and if it has ever been edited. Easy enough to do on a well written Access database, never heard of it on an Excel one. However, I willing to bet a fair bit of cash that there's no such protection on the Seahorse Trust database, if it in fact exists.

As a professional data manager, the bane of my life was data collected in Excel; I must have wasted months in importing Excel data into a proper database! Excel is excellent as a means of carrying out some kinds of analysis, but it has the following shortcomings for data management:

1) No data validation (i.e. is it a number? is it a date? Does the value fall in a required range? If category data is it validated against a list? If text, does it follow a prescribed format?)
2) Data of different types can be mixed in the same column.
3) No proper concept of null values, and people tend to make up their own!
4) No audit trail (who entered or edited the data and when)

A proper database (and Access is only suitable for small applications; Oracle, PostGreSQL and MySQL are more widely used) will have all of these built in, so it is a) impossible to mix data types in a particular column, b) automatically applies data validation (if the author has done his/her job properly) c) has a proper, robust null value concept and d) provides an audit trail if required.
 
As a professional data manager, the bane of my life was data collected in Excel; I must have wasted months in importing Excel data into a proper database! Excel is excellent as a means of carrying out some kinds of analysis, but it has the following shortcomings for data management:

1) No data validation (i.e. is it a number? is it a date? Does the value fall in a required range? If category data is it validated against a list? If text, does it follow a prescribed format?)
2) Data of different types can be mixed in the same column.
3) No proper concept of null values, and people tend to make up their own!
4) No audit trail (who entered or edited the data and when)

A proper database (and Access is only suitable for small applications; Oracle, PostGreSQL and MySQL are more widely used) will have all of these built in, so it is a) impossible to mix data types in a particular column, b) automatically applies data validation (if the author has done his/her job properly) c) has a proper, robust null value concept and d) provides an audit trail if required.

Exactly right. I was going to say that just putting the data into an Access database doesn't make it any better than Excel. I used to run into home-brewed Access files a lot and they tended to be really rubbish. Usually one or two tables, all fields set to default 50 character text (even dates and sometimes numbers) and nothing to make a record unique. Usually a fair bit badly written code to bodge a front end. Often very little better than Excel.

Access is only suitable for small systems but I did implement one or two for around 50 users without much of a problem. The design is key and then it requires good implementation to ensure data integrity. I hated people programming fixes to work around basic problems with the design.

It sounds as if we had similar experiences with people rolling their own solutions in Excel or Access.
 
Last edited:
Top