Bug-Jagd - Fehlende bzw. falsche Indizes

[webald]

Tabelle zones_to_geo_zones:

Welchen Nutzen hat die Spalte zone_id?

Diese ist immer 0 und nutzt nicht die Einträge in Tabelle zones

[webald]

Tabelle geo_zones:

geo_zone_id = 6 sollte umbenannt werden: Steuerzone EU-Ausland hört sich an wie Ausland aber in der EU. Ich bin für Nicht-EU-Ausland.

geo_zone_name sollte eindeutig sein.

Code: SQL  [Auswählen]

ALTER TABLE geo_zones ADD UNIQUE (geo_zone_name)

EDIT:
Ich wäre dann jetzt erstmal durch. 

[webald]

Zu früh gefreut. Tabelle banktransfer:

Darf orders_id mehrfach vorkommen? Falls Nein falscher Index.

Code: SQL  [Auswählen]

ALTER TABLE banktransfer DROP INDEX orders_id
ALTER TABLE banktransfer ADD PRIMARY KEY (orders_id)

Und wo wird im Shop eigentlich der Status (banktransfer_status) gesetzt?

[noRiddle (revilonetz)]

Ich finde wirklich, daß das ganze ein Ticket wert ist...

Gruß,
noRiddle

[webald]

Is ja gut...

aber darf denn nun in der Tabelle banktransfers die order_is merhfach vorkommen oder nicht? Theoretisch könnte man diese Tabelle auch so verstehen/nutzen, dass man jede Änderung am Status dort speichert/protokolliert oder auch Transfers von mehreren Konten für eine Order ermöglicht.

[noRiddle (revilonetz)]

Schau dir doch das Modul /includes/modules/payment/banktransfer.php an.
Da dort die Variable $insert_id (nachdem sie global gemacht wurde) für die orders_id benutzt wird, dürfte orders_id UNIQUE sein.
Ein PRIMARY KEY sollte also möglich sein. Lediglich ein UNIQUE KEY würde theoretisch NULL Values zulassen, orders_id ist aber NOT NULL.
Fakt ist aber auch, daß ein normaler KEY, wie auch gesetzt, ausreichend wäre für die WHERE-Clauses in den SELECT-Statements.
Nach meinen Recherchen soll ein PRIMARY KEY zwar noch schneller sein als ein normaler KEY bei SELECT-Statements, allerdings nur wenn die ENGINE=InnoDB.
Bei ENGINE=MyISAM ist ein PRIMARY nicht schneller in SELECT-Statements als ein normaler KEY.

Gruß,
noRiddle

[webald]

Ticket # 374

[webald]

Tabelle products_to_categories:

Code: SQL  [Auswählen]

ALTER TABLE products_to_categories DROP PRIMARY KEY,
ADD PRIMARY KEY (categories_id, products_id)

sowie

Code: SQL  [Auswählen]

ALTER TABLE products_to_categories DROP INDEX idx_categories_id,
ALTER TABLE products_to_categories ADD INDEX (products_id)

Meine Tests haben ergeben, dass die Suche nach Kategorien und den Darin enthaltenen Artikeln so weniger Zeilen durchsuchen muss. Das kann u. U. bei vielen Artikeln und Kategorien helfen.

Beim OK ist lediglich die Reihenfolge der Felder geändert. Da der Index aber nur in der Reihenfolge der Felder genutzt wird, kann bei einer Suche nach der Kategorie im Standard der PK nicht greifen. Die Suche nach einem Artikel und den Kategorien in denen er enthalten ist macht nicht so viel Sinn, dafür gibt es den Index auf products_id.

Hat da einer eine gegenteilige Meinung?

[webald]

Hab ich was übersehen oder schnmitgeteilt?

Code: SQL  [Auswählen]

ALTER TABLE manufacturers DROP INDEX idx_manufacturers_name;

ändern zu

Code: SQL  [Auswählen]

ALTER TABLE manufacturers ADD UNIQUE(manufacturers_name);

[webald]

In 2.x hat im Frontend die Sortiermöglichkeit der Artikelauflistung Einzug gehalten. In der Datenbank sind aber für diese Sortiermöglichkeiten z. T. keine Indizes angelegt:

Code: SQL  [Auswählen]

ALTER TABLE products ADD INDEX(products_price);
ALTER TABLE products ADD INDEX(products_sort);
 

ebenfalls gibt es keinen Index für EAN, dieser wird aber im Suchfeld ebenfalls durchsucht. Gleiches für ie Keywords, daher

Code: SQL  [Auswählen]

ALTER TABLE products ADD INDEX(products_price);
ALTER TABLE products_description ADD INDEX(products_keywords);