Attribut-Konventionen

Status: Entwurf

Konventionen für entity_type_attribute-Einträge, die im Mapping verwendet werden.

Naming

key ist lower_snake_case, eindeutig je entity_type
Deutsche Fachbegriffe als key zulässig (baujahr, dachform, nettomiete), aber konsistent
Englisch nur für globale Konzepte (status, code, name, created_at)
Kein Mix je entity_type — entweder ganz deutsch oder ganz englisch (Vorgabe für UI / Reporting)

Datentypen (Spec-Set)

data_type ∈ text, number, boolean, date, datetime, enum, multi_enum, reference, multi_reference, json

Fachlich	`data_type`	Bemerkung
Adresse strukturiert	`json` mit Schema	bis OP-39 Geo eingebaut
Datum (Datum ohne Zeit)	`date`
Geld	`number`	bis OP-39 `money`-Typ eingeführt; Währung als zweites Attribut `<feld>_currency` (`eur` Default)
Menge mit Einheit	`number`	bis OP-39 `quantity`-Typ; Einheit als zweites Attribut
Codeliste	`enum`	Referenz auf `enum_set`
Codeliste mehrfach	`multi_enum`
Beziehung 1:1	`reference`	Referenz auf `relation_type`
Beziehung 1:n	als `entity_relation` modelliert, nicht als Attribut
Anhang / URL	`text` mit Konvention oder `attachment`-Relation	siehe Spec OP-40

Pflicht / optional

is_required (Pflicht) wird in entity_type_attribute gesetzt. Datentypen mit Constraint:

enum mit is_required=true ⇒ Wert aus enum_set.values
reference mit is_required=true ⇒ Beziehung muss zur Anlage-Zeit existieren
text mit is_required=true ⇒ nicht leer und nicht nur whitespace

Eindeutigkeit

is_unique_per_type=true bewirkt Unique-Constraint je (tenant_id, entity_type_id) über alle nicht-soft-gelöschten Records.

Beispiele:

Attribut	`is_unique_per_type`	Begründung
`provider.tax_id`	ja	USt-ID ist je Land eindeutig
`subsidiary.register_no`	ja	Handelsregister
`material.hersteller_code`	ja je Hersteller — Composite	nicht via Attribut, eher via UQ-Index in DDL
`pv_system.marktstammdaten_id`	ja	regulatorisch eindeutig
`contract.code`	ja je Provider	Composite

Suchbarkeit

is_searchable=true ⇒ Attribut fließt in search_vector ein (Spec-Trigger entity_before_write).

Defaultmäßig:

name, code immer searchable
text-Attribute meist searchable
numerische / Datums-Attribute nicht searchable (außer Sortier-Filter, da via Expression-Index)

Sortierbarkeit / Filter

is_filterable=true und is_sortable=true lösen Expression-Indexe aus (Spec OP-17 — Mechanik in Diskussion).

Konvention: bei den am häufigsten gefilterten Attributen true setzen, bei seltenen false (Performance).

Validation Rules (offen)

validation_rule jsonb ist im Spec offen (OP-14). Vorerst Konventionen:

Min/Max für numerische Werte: { "min": 0, "max": 1000 }
Regex für Text: { "pattern": "^[A-Z]{2}\\d{9}$" } (z. B. USt-ID)
Datum-Bereiche: { "min": "2000-01-01", "max": "2099-12-31" }
Cross-Field: später, mit Rule Engine (60-rules-and-calculation/01-rule-engine-intent.md)

Default-Werte

default_value als Text — wird beim Speichern als entsprechender Datentyp interpretiert. Beispiele:

subsidiary.kategorie Default: bau
case.status Default: draft
contract.kuendigungsfrist_tage Default: 90
building.dachform kein Default — Pflicht

Reihenfolge in UI

order_index (oder sort_order) bestimmt, in welcher Reihenfolge Attribute in Formularen erscheinen. Konvention: Pflichtfelder oben, optionale unten.

I18n (offen)

Aktuell einsprachig (deutsch). I18n der Labels über separate Tabelle (Spec OP-37/38) — Mechanik offen.