Mercurial > gemma
view wamos.sql @ 38:529319bc3c5b
Mark gauges table as placeholder.
author | Tom Gottfried <tom@intevation.de> |
---|---|
date | Fri, 04 May 2018 19:06:29 +0200 |
parents | 6f273a649f08 |
children | 830287983657 |
line wrap: on
line source
BEGIN; CREATE EXTENSION postgis; CREATE FUNCTION update_date_info() RETURNS trigger LANGUAGE plpgsql AS $$ BEGIN NEW.date_info = CURRENT_TIMESTAMP; RETURN NEW; END; $$; -- Composite type: UN/LOCODE, fairway section, object reference, hectometre. -- See RIS-Index Encoding Guide CREATE TYPE isrs AS ( country_code char(2), -- ISO 3166 country code -- could be validated against countries table. locode char(3), -- without the country code: -- http://www.unece.org/cefact/locode/welcome.html fairway_section char(5), object_reference char(5), hectometre int -- should be constrained to five digits ); CREATE TYPE isrsrange AS RANGE ( subtype = isrs ); CREATE TABLE rwdrs ( stretch isrsrange PRIMARY KEY, -- https://www.postgresql.org/docs/10/static/sql-createindex.html: -- Only B-tree supports UNIQUE indexes, but we need the GIST index -- below anyhow. -- Is it a good idea to build B-tree indexes on relatively large -- composites of string values or should we use inter PKs? -- => In case the index is used and cache space becomes a limiting -- factor, this might be an issue. rwdr double precision NOT NULL, EXCLUDE USING GIST (stretch WITH &&) ); CREATE TABLE gauges ( location isrs PRIMARY KEY, dummy_attrib varchar -- TODO: add real gauge attributes (DRC 2.1.4) ); CREATE TABLE countries ( country_code char(2) PRIMARY KEY -- ISO 3166 country code -- A smallint PK would require even less disk space i.e. on the FK side. -- This might be an issue in case cache space becomes a limiting -- factor when there are many FKs pointing here. ); CREATE TABLE riverbed_materials ( material varchar PRIMARY KEY ); CREATE TABLE survey_types ( survey_type varchar PRIMARY KEY ); CREATE TABLE coverage_types ( coverage_type varchar PRIMARY KEY ); CREATE TABLE limiting_factors ( limiting_factor varchar PRIMARY KEY ); CREATE TABLE depth_references ( depth_reference char(3) PRIMARY KEY -- Possible codes? char(3) ok? ); CREATE TABLE bottlenecks ( bottleneck_id varchar PRIMARY KEY, -- XXX: Why encoding three different data in the ID as described in -- DRC? fk_g_fid isrs REFERENCES gauges, -- XXX: DRC references "ch. 3.1.1", which does not exist in document. objnam varchar UNIQUE NOT NULL, nobjnm varchar UNIQUE, stretch isrsrange NOT NULL, rb_lb varchar, -- XXX: Why two data in one attribute? Why not: rb char(2) NOT NULL REFERENCES countries, lb char(2) NOT NULL REFERENCES countries, riverbed varchar NOT NULL REFERENCES riverbed_materials, -- XXX: list of materials differs between IENC Encoding Guide and DRC responsible_country char(2) NOT NULL REFERENCES countries, revisiting_time smallint NOT NULL, surtyp varchar NOT NULL REFERENCES survey_types, -- XXX: Not an attribut of sounding result? coverage varchar NOT NULL REFERENCES coverage_types, -- XXX: Not an attribut of sounding result? -- CHECK allowed combinations of surtyp and coverage or -- different model approach? limiting varchar NOT NULL REFERENCES limiting_factors, depth_reference char(3) NOT NULL REFERENCES depth_references, -- XXX: Not an attribut of sounding result? date_info timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, source_organization varchar NOT NULL, additional_data xml -- XXX: What is that really for? ); CREATE TRIGGER bottleneck_date_info BEFORE UPDATE ON bottlenecks FOR EACH ROW EXECUTE PROCEDURE update_date_info(); CREATE TABLE vertical_references ( vertical_reference varchar PRIMARY KEY ); CREATE TABLE sounding_results ( bottleneck_id varchar NOT NULL REFERENCES bottlenecks, date_info date NOT NULL, PRIMARY KEY (bottleneck_id, date_info), area int, -- XX: Check SRS/test data what this should be type int, -- XX: Check SRS/test data what this should be vertical_reference varchar NOT NULL REFERENCES vertical_references, sounding_data raster NOT NULL ); COMMIT;