part of SQL statements, or in PostgreSQL, with a JSON data type that can be indexed and queried. These developments accomplish, improve or substitute the EAV model approach. The uses of JSON and XML are not necessarily the same as the use of an EAV model, though they can overlap. XML is preferable to EAV for arbitrarily hierarchical data that is relatively modest in volume for a single entity: it is not intended to scale up to the multi-gigabyte level with respect to data-manipulation performance. XML is not concerned per-se with the sparse-attribute problem, and when the data model underlying the information to be represented can be decomposed straightforwardly into a relational structure, XML is better suited as a means of data interchange than as a primary storage mechanism. EAV, as stated earlier, is specifically (and only) applicable to the sparse-attribute scenario. When such a scenario holds, the use of datatype-specific attribute–value tables that can be indexed by entity, by attribute, and by value and manipulated through simple SQL statements is vastly more scalable than the use of an XML tree structure. The Google App Engine, mentioned above, uses strongly-typed-value tables for a good reason. Graph databases An alternative approach to managing the various problems encountered with EAV-structured data is to employ a graph database. These represent entities as the nodes of a graph or hypergraph, and attributes as links or edges of that graph. The issue of table joins are addressed by providing graph-specific query languages, such as Apache TinkerPop, or the OpenCog atomspace pattern matcher. Another alternative is to use SPARQL store. Considerations for server software PostgreSQL: JSONB columns PostgreSQL version 9.4 includes support for JSON binary columns (JSONB), which can be queried, indexed and joined. This allows performance improvements by factors of a thousand or more over traditional EAV table designs. A DB schema based on JSONB always has fewer tables: one may nest attribute–value pairs in JSONB type fields of the Entity table. That makes the DB schema easy to comprehend and SQL queries concise. The programming code to manipulate the database objects on the abstraction layer turns out much shorter. SQL Server 2008 and later: sparse columns Microsoft SQL Server 2008 offers a (proprietary) alternative to EAV. Columns with an atomic data type (e.g., numeric, varchar or datetime columns) can be designated as sparse simply by including the word SPARSE in the column definition of