Mitglieder-Gruppen Zuordnung

[Ludwigmller]

Hallo,
Nehmen wir an, ich möchte mehrere Mitglieder einer Gruppe zuordnen. Die id_mitglieder liegt als integer vor und ist Primärschlüssel der Tabelle mitglieder. Welche Vor- und Nachteile haben die beiden Varianten:
eine Tabelle zuordnung mit zwei Spalten id_gruppe und id_mitglieder in der
1) eine Gruppe und ein Mitglied gespeichert ist, sodass für eine Gruppe mit 5 Mitgliedern 5 Tupel erstellt werden oder
2) eine Gruppe und ein integer array aus Mitgliedern gespeichert ist, also unabhängig von der Mitgliederzahl nur ein Tupel erstellt wird

Gruß
Ludwig

 

[dabadepdu]

1 ist mehr oder weniger Standard und bequem zu handhaben mit SQL Bordmitteln
2 ist nicht in allen DB möglich [array] und bei der Verarbeitung, Reporting u.U. ineffizient. (Indizierung, ..)

Vorteil mag sein, dass 2 platzsparend scheint, falls Du darauf hinaus willst. Aber ich würde ohne Not soetwas nicht machen. Und wir leben in einer Zeit, wo Speicher nicht mehr so teuer ist. Es war mal üblich, die Daten in Strukturen zu speichern oder Protokollen zu verarbeiten, die Bytegrenzen ignoriert haben, einfach aus Platzgründen. Das ist in der Form nicht mehr notwendig.

Not: Gigantische Datenbestände, mit sehr seltener Nutzung dieser Relation und dann ggF. extrem ausgeprägter oder sowas.

 

[ukulele]

Im Prinzip ist nur Variante 1) für den Gebrauch in relationalen Datenbanken sinnvoll. 2) geht eher in die Richtung XML, das kann z.B. für den Export und die Weitergabe von daten interessant sein oder für NoSQL Modelle. Im Fall 2 wäre z.B. eine Abfrage "gib mir alle Gruppen, in der eine Person Mitglied ist" sehr unperformant. Du müsstest theoretisch alle Arrays aus der Tabelle lesen.

 

[akretschmer]

Im Fall 2 wäre z.B. eine Abfrage "gib mir alle Gruppen, in der eine Person Mitglied ist" sehr unperformant. Du müsstest theoretisch alle Arrays aus der Tabelle lesen.

da der Fragesteller PostgreSQL verwendet könnte er dazu Indexe nutzen:

postgres=# create table a_demo(a int[]);
CREATE TABLE
postgres=# insert into a_demo select array[1,2,3];
INSERT 0 1
postgres=# insert into a_demo select array[10,20,30];
INSERT 0 1
postgres=# create index idx_array on a_demo using gin (a);
CREATE INDEX
postgres=# explain analyse select * from a_demo where a @> array[1];
                                           QUERY PLAN                                            
-------------------------------------------------------------------------------------------------
 Seq Scan on a_demo  (cost=0.00..1.02 rows=1 width=32) (actual time=0.031..0.041 rows=1 loops=1)
   Filter: (a @> '{1}'::integer[])
   Rows Removed by Filter: 1
 Planning Time: 0.540 ms
 Execution Time: 0.147 ms
(5 rows)

postgres=# set enable_seqscan to off;
SET
postgres=# explain analyse select * from a_demo where a @> array[1];
                                                    QUERY PLAN                                                    
------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on a_demo  (cost=8.00..12.01 rows=1 width=32) (actual time=0.034..0.058 rows=1 loops=1)
   Recheck Cond: (a @> '{1}'::integer[])
   Heap Blocks: exact=1
   ->  Bitmap Index Scan on idx_array  (cost=0.00..8.00 rows=1 width=0) (actual time=0.017..0.022 rows=1 loops=1)
         Index Cond: (a @> '{1}'::integer[])
 Planning Time: 0.310 ms
 Execution Time: 0.434 ms
(7 rows)

postgres=#

Das `set enable_seqscan to off;` ist nötig wegens Kostenmodell und zu kleiner Tabelle ...