Re: [bufrtables] BUFR and GRIB2 table information in relational DB?

Dear Jeff,

CMC is working on putting its BUFR tables into a relational database. Our main 
goal is relatively modest: it is to provide a web-based human interface to 
browse and update the Tables, to replace the error-prone process of manually 
updating a large ASCII file. But we are mindful of other possible advantages 
such as improved programming interface.

We have a working prototype of a Table B interface. It is composed of a PHP 
front-end and MySQL back-end. We can enter new descriptors, change their status 
(validation, pre-operational, operational), even change descriptor definition 
while maintaining traceability and descriptor history across Table version 
numbers.  We want to be able to ingest directly WMO computer-friendly Table 
updates, verify them and accept them into our operational system. Furthermore 
we want to be able to publish Tables in backward-compatible ASCII formats. 

Development has been slow, due to other projects competing for the resources, 
but it is progressing. Our next step would be to develop a similar interface 
for Table D.  We also need to integrate code and flag tables that are referred 
to by Table B descriptors.

We can talk about this more, off-line, if you wish.

Best regards

Yves

-----Message d'origine-----
De : Jeff Ator [mailto:Jeff.Ator@xxxxxxxx] 
Envoyé : 16 June, 2011 13:00
À : Eric Wise; Paul Zamiska; leslie.baran@xxxxxxxx; Lamar Troutman; Enrico 
Fucile; Sibylle Krebber; Atsushi Shimazaki; Eizi Toyoda; Richard Weedon; 
Pelletier,Yves [CMC]; Simon Elliott; Jose Mauro de Rezende; Weiqing Qu; Stan 
Kellett; bufrtables@xxxxxxxxxxxxxxxx
Objet : BUFR and GRIB2 table information in relational DB?

Hi Everyone,

This is more of a general survey question.  Here at NCEP, we currently have our 
BUFR and GRIB2 master table information scattered across a bunch of ASCII 
tables, web pages and system files.  We're thinking about designing and 
implementing a relational database to store all of this information in one 
place, and then developing methods to allow the information to be easily 
exported from the database into the specific formats we need for all of our 
APIs and other operational tasks.  We believe the BUFR and GRIB2 tables lend 
themselves well to relational database design (especially when multiple 
versions of tables including local entries need to be stored), and having one 
master repository would alleviate problems we're currently having keeping 
information synchronized across multiple system files and documents.

My question is, has anyone out there ever done or thought about doing this type 
of thing?  If so, we'd be interested to correspond with you about your 
experiences, issues encountered, best practices, etc. and explore any possible 
avenues for collaboration.  It's hard for us to believe that nobody else has 
ever thought of this before, so if at all possible we'd like to benefit from 
any existing experience in the community and avoid re-inventing the proverbial 
wheel.

Please let me know if you have any thoughts or experience in this area that 
you'd be willing to share.  Either way, thanks for your time and consideration!

With best regards,
-Jeff