I would go the complicated way:
Two Tables in a 1:n relation
one table with the point location of the graves
another table with the Grave-ID and person data
You can build a relation between the two tables so that selecting a grave will select all person records in the person-table.
The idea of having tables with fields like Person1, Person2... is ...
Unfortunately, some of those feature are deeply dependent of the piece of software you use.
For example, let's take the U-Turns in ArcGIS and PGRouting. In ArcGIS, it is something you can choose as an option, in PGRouting, it is nested in the code.
On way street can be processed in two way. The are set up part of the graph with a very high cost (PGRouting)...
Here's a draft logical data model I've been told (unofficially) they are working on implementing at Colorado DOT. It is geared for ArcGIS, but I think it is generic enough to borrow parts of for use in PostGIS without having ArcSDE.
It is not clear to me how (or if) this data model fits into the Rome project at Esri.
Also check out Designing ...
I'm assuming ArcGIS Desktop ... Use relates in the map or relationship classes in the geodatabase.
From the ArcGIS Desktop 10 help files with my emphasis below:
"Unlike joining tables, relating tables simply defines a relationship between two tables. The associated data isn't appended to the layer's attribute table like it is with a join. Instead, you can ...
It is generally advisable to seperate layers by tables. It sounds like you have a need for a dynamic schema, you may want to look at Postgres's hstore extension, it can let you set up a key->value pair field that may suit your needs.
I would create a polygon for the grave since the grave itself is a plot of land and have a one to many relationship for the people; one grave can have zero (unoccupied, available, or for sale ?) or many people. You could also use a point instead of the polygon. Polygons would make better presentations for sales and maintenance.
Personally, I would approach this from a database perspective rather than either a GIS perspective or a spreadsheet perspective.
I would have one table of boreholes. This would contain the fields of BoreholeId, and Geometry. Records would obviously be the values.
I would then have another table of BoreholeData. This would contain the fields of ...
Based on the additional information in your comment, there are a few things you could do. One thing to remember is that flexibility is key. If you put all of your polygon features in one table and all of your point features in another table, it makes it very difficult to compare different features. For example, if you have a polygon layer that ...
I would take DenaliHardtail's suggestion of using polygons to represent accurate sizes of the plots. This layer could have a table with Grave_ID, Grave_Type, Grave_Capacity, and Grave_Occupancy_Number. Then you could have a point layer with points overlying the corresponding grave polygons. Columns for the point layer table could be Person-ID, First_Name, ...
Let's start with some assumptions:
You really need 5000 web requests per second, and
It would be possible to service those requests in only 5 seconds, and
The queries could be serviced by exactly one CPU core, and
Each core only needs 4GB of RAM, and
The optimal core to CPU chassis distribution is 32, and
Each CPU chasis has enough SSD disk to service all ...
Beyond the technical elements, another thing that you might consider is the people aspect of a GIS. It's important to have people trained in how to process the data, and how to interpret the results that you get. Otherwise, you just have a bunch of data.
Geographic Information Framework Data Content Standard, Part 7c: Transportation - Roads
INSPIRE Data Specification on Transport Networks – Guidelines
They have some of what you're after but they are really broad. You don't state your use case. Just make sure you don't do more than you need to.
Please state what platform you are working with. If you are working with ArcGIS, I think you want to use relationship classes, which are tables which define a connectivity between feature points of different layers ( such as a company point layer and a table holding all employees). Holding them all in a single huge layer isn't practical.
Some (slightly) theoretical pointers:
Instead of focusing on attributes, one approach to the problem might focus on exploring characteristics of movement patterns. Those could be explored by calculating aggregated characteristics of movement or dividing your data into logical 'chunks' (for instance, daily trajectories of certain objects). At next stage you ...
I would personally use arcpy.MakeQueryTable_management and then use that table to create a new featureclass with that as its template.
Please note, that the layer that is created by the tool is temporary and will not persist; you have to use the item created by this, in creating a permanent table
Alternatively, you could just code the creation of the table ...
If you want to assign IDs (or another field) automatically, you should programmatically create Class Extension that listens to edit events and updates corresponding Id field
You just need to create a new field in your feature class and use the Field Calculator to create the unique ID based on fields in the class. Something like:
"CH%s%s" % (!StreetField!, !UniqueCodeField!)
Normalizing the data leads me to some missing ideas/points. Also, I think Excel can do everything you want for the "database" you contemplate. Hint: Use sheets, or multiple files and use variations of Lookup functions. Save into the useful file(s) for imports/lookups from QGIS
I envision these discrete tables [or excel sheets], to start off your data set....
You should add a PostGIS extension, and use the geometry type instead. It will handle 30000 features easily, and work with many GIS systems (e.g. QGIS). You can always extract the WKT equivalent from a geometry column using ST_AsText.
Here's an example workflow, assuming it's a table in postgres
--Say you have a table described in your question
CREATE TEMP ...
I don't have enough reputation to comment on the accepted answer, so here is just some updated information about sharding geopstial data in MongoDB.
Current with version 3.2.9 (Sept 2016) you cannot use a geospatial index as a shard key
A shard key index cannot be an index that specifies a multikey index, a text index or a geospatial index on the shard ...
This can be done with PostGIS's ST_LocateBetween function, where you can extract point and linestrings from either a single time or between a range of times. To do this, you need to have geometries with a measure dimension, that is [Multi]Point [Z]M or [Multi]LineString [Z]M geometries. A numeric timestamp (e.g. Unix time) can be used for the M-dimension.
It might be worth looking at the Infrastructure Network Editing (ArcGIS 10) to see if the attribute assistant can be configured to create your IDs. I don't recall if it can be used outside of a network.
Infrastructure Network Editing also includes an editor extension
PostGIS can do what you're talking about. I have it set up on a laptop for personal use, but if I wanted to expand it out simply dumping the data and loading it onto a more traditional server would be sufficient.
You can use Postgres's roles to define admin and read only accounts.
To back up the data you can set up a cron job that runs pg_dump and ...
You can get what you want by standing up a database service using Amazon RDS, and then installing a web-accessible database management on another system. This would permit you and your client to make queries against the database without requiring any software installation on your local computer.
If you are familiar with EC2 and basic system administration, ...
Partitioning is most beneficial when you can couple it with a constraint that will allow the planner to exclude certain child tables entirely from most queries. Unfortunately, this currently isn't possible to do with a spatial constraint, but you might be able to take advantage of it by partitioning roads by country or state, and including the state or ...
Problem is not in relation with pk or fk but with Unique IDs in the SDE environment.
It's recommended to use in all tables (featureclass) GlobalIDs and others GUID fields.
A relationship class facilitates one-to-one, one-to-many, or many-to-many relationships, using GUIDS (or other fields, but GUIDS are recommended).
GUIDS and relationship classes are ...
Warning: Any modifications to the underlying tables in an enterprise geodatabase are likely to be unsupported and should be tested and re-tested (in a non-production test environment) before you even think about trying it in your production database.
Also note: You will be more likely to get a definitive answer to your question by asking Esri directly ...
There is no such thing as a geodatabase. I'll answer in the abstract. That's just marketing wank, there is a database and some of them support spatial types. They can be implemented with all kinds of models: inheritance, relational, hierarchical (ldap, snmp, etc.) And, they can have all different models of concurrency (MVCC, and eventual consistency, etc).