Mehrere Artikel löschen

Hallo zusammen,

gibt es eine Möglichkeit mehrere Artikel in einem “Rutsch” zu löschen?

Ich kann zwar mehrere Artikel aus den Kategorien löschen, diese Kategorien sind nun alle leer.
Aber nun habe ich alle Demoartikel (die ja nicht mehr in Kategorien zugeordnet sind) und müsste die unter Artikel mit dem x auf der rechten Seite alle [U][B]einzeln löschen[/B][/U]. Das erscheint mir etwas umständlich. Geht das auch anders, gibt es eine “Mehrfachselektion” zum Artikel löschen ?

Klaus

1 Like

Leider über den Admin wohl nicht, das geht wohl nur direkt über SQL. Ist mir auch schon als einer der wenigen NEGATIV-Punkte von OXID aufgefallen.

mfG

Michael

kaum zu glauben,
dass es bei einer shop-software, die ab dreitausend euro kosten soll, keine möglichkeit gibt im adminbereich mehr als nur jeweils einen artikel zu löschen.

ist das wirklich wahr ??? des gibts doch ned, oder ??? dann bin ich ja wirklich heilfroh, erstmal die ce version zum test installiert zu haben, bevor ich den geldbeutel geöffnet habe. uff

klaus

kaum zu glauben
Glaubs ruhig !

Hehe, vor ca. 1 1/2 Jahren hab ich das auch gefragt.

Ich konnte das auch irgendwie nicht begreifen, wir hatten vorher einen xtCommerce-Shop, und da is das viel komfortabler gelöst. Wir haben zwar ne Warenwirtschaft, aber manchmal hat man schon größere Posten zu löschen, und da wär das nich schlecht wenn man mehrere Artikel markieren kann.

Mir wurde dann empfohlen das als Feature-Request zu beantragen. :slight_smile:

Aber wahrscheinlich vermisst das sonst keiner weiter. Der OXID-Shop hat ja ansonsten auch par Qualitäten, da muss man sich ggf. dran gewöhnen.

mfg

500 oder mehr artikel einzeln zu löschen ist ja schon etwas aufwändig, noch dazu wenn diese arbeit öfter zu verrichten ist.
wenn ich über phpmyadmin in der tabelle oxarticle die entsprechenden zeilen lösche, würde des funktionieren oder ist das mit großer gefahr verbunden ?

klaus

wer 500 auf einmal löschen muß, geht definitiv via myadmin und sql
ich denke einfach, daß die überarbeitung des admins stehen geblieben ist, da sind so viele dinge “reingeklatscht” weils rechtlich z.b. neu dazu kam wie grundpreise
und anderes ist unmögliches handling, wenn man variantenbearbeitung incl. abc und staffelpreise macht
alles in allem hoffe ich beim redesigning des admins wird auch darauf rücksicht genommen

Leichen in den verbundenen Tabellen.

Genau das ist das eigentliche OXID-Problem, denn in einer vernünftig organisierten relationalen Datenbank würde es diese Leichen einfach nicht geben.

mfG

Michael

[QUOTE=modellzentrum;38640]Genau das ist das eigentliche OXID-Problem, denn in einer vernünftig organisierten relationalen Datenbank würde es diese Leichen einfach nicht geben.

mfG

Michael[/QUOTE]

Sobald du verknüpfte Daten auf mehrere Tabellen verteilst (was durchaus Sinn macht), kann man nun halt nicht mehr einfach einen Datensatz löschen, ohne das Leichen übrigbleiben. Da ist dann eben eine Funktion notwendig, um Daten zu löschen.
Wenn du das Mehrfachlöschen unbedingt brauchst, dann entwickle es doch oder lass es durch einen Partner entwickeln.

Wieso kann / will man überhaupt Artikel löschen ? Gehen dann nicht auf wichtige Infos verloren zu den Bestellungen etc. verloren. Was passiert denn mit den Bestellungen bei denen die Artikel enthalten waren etc.? (Ganz abgesehen von den oxartextend , oxcategories oxobject2artcicle etc.)

Ganz so einfach ist das wirklich nicht. Würde alleine aus “Revisionsgründen” versuchen keine (verkauften) Artikel zu löschen.

CYA

Sorry lieber Moderator Roland,

aber da fehlt Dir wohl echt das Wissen über eine relationale Datenbank und die entsprechenden Tabellenverknüpfungen, die in einer solchen möglich sind, denn selbstverständlich werden in einer solchen Datenbank ALLE Einträge in diversen Tabellen VOLLAUTOMATISCH gelöscht, die mit dem Artikel zu tun haben. So etwas nennt man “Löschweitergabe”. Im Beispiel des Webshops halt nicht nur der Eintrag in der OXARTICLE, sonder auch alle Einträge in den Kategorien oder auch alle Bestellungen je nach Wunsch und Konfiguration der Beziehung, die die Tabellen unterhalten bzw. wie diese Beziehungen eingerichtet worden sind. Aber zum Glück kann man sich solche Leichen ja auch via SQL heraussuchen und dann löschen, zumindest soweit man auf die komischen OXID-Werte verzichtet, denn dann kann man die Inhalte der Tabellen auch lesen.

Und in meiner Branche gib ts jährlich ca. 10.000 neue Artikel und natürlich die gleiche Menge Artikel die entfallen, wie groß soll die Datenbank dann werden?

mfG

Michael

Beispiele:
Welche Einträge in OXOBJECT2CATEGORIE sind über, weil die Artikel gelöscht wurden?:
SELECT * FROM oxobject2category WHERE OXOBJECTID NOT IN (SELECT OXID FROM oxarticles )
Sinngemäß natürlich auch für OXARTEXTENDS etc.
Löschen solcher Einträge:
DELETE FROM oxobject2category WHERE OXOBJECTID NOT IN (SELECT OXID FROM oxarticles )

Deshalb habe ich ja kein Problem mit der fehlenden Multilöschfunktion, da ich Sie durch SQL Abfragen ersetzt habe

jetz hab ich alles verstanden, klar, super.

ich geh jetzt ein bier trinken und melde mich danach zu einem informatikstudium an *lol

klaus

  • das leben könnte soooo einfach sein - wenn entwickler an unbedarfte anwender und deren bedürfnisse denken würden und den anwendern nicht nur das verkaufen was sie im stande sind zu entwickeln, sondern sondern lernen zu entwickeln was der kunde braucht.
    und da gehört nun mal das löschen von artikeln (und ich spreche von mehreren auf einmal) dazu.

das wäre dann ein weiterer schritt zur benutzerfreundlichkeit !!!

somit schliesse ich dieses thema ab !!!

**** eof ****

Sorry lieber Datenbank-Guru Michael

Es scheint so, als hätte ich doch wirklich eine falsche Aussage getätigt. Aber schön, dass du uns aufgeklärt hast.

:slight_smile: ich würde jetz auch gern ein Bier trinken

[QUOTE=modellzentrum;38647]
Und in meiner Branche gib ts jährlich ca. 10.000 neue Artikel und natürlich die gleiche Menge Artikel die entfallen, wie groß soll die Datenbank dann werden?
[/QUOTE]

Sorry, aber das sind Peanuts für eine DB!

Hast du Logs aktiviert ? Wieviele Zeilen kommen da an einem Durchschnittstag dazu ? Meiner Meinung nach versuchst du hier etwas zu optimieren was zu suboptimalen Ergebnissen führt und keiner Optimierung bedarf.

Das man das machen kann, steht außer Frage. Ob es Sinnvoll ist kann jeder selbst beurteilen. Ich würde davon abraten!

Was passiert mit den Artikeln in den bestehenden Bestellungen ? Ohne es jetzt zu testen vermute ich das es spätestens dort zu Problemen kommt.

eine bestellung aus 2004, ein gelöschter artikel, also einer der NICHT via datenkbank gelöscht sondern direkt via admin

wenn mans ganz genau nimmt, zählt oxid die leichen sogar nach zig jahren immer noch mit bei den top of the shop artikeln
meiner meinung nach auch falsch, wenn artikel tot, nimmer kaufbar, eben leiche und nicht mehr existent, gehört er auch aus den top/shop raus

Hallo,

wir haben uns aus Performancegründen bewußt dafür entschieden, die Datenbankstrukturen relativ flach zu halten.
Sicherlich wäre es schön, mehrere Artikel gleichzeitig löschen zu können. Dieses Feature wird auch ganz gewiß bei der Runderneuerung des Admins Beachtung finden.

Gruß

somit schliesse ich dieses thema ab !!!

**** eof ****

[QUOTE=Firefax;38661]Was passiert mit den Artikeln in den bestehenden Bestellungen ? Ohne es jetzt zu testen vermute ich das es spätestens dort zu Problemen kommt.[/QUOTE]
Da passiert nix, da die Bestellungen nicht mehr Artikel in der Datenbank referenzieren, sondern alle notwendigen Artikeldaten in der Bestellung selbst gespeichert werden.

trotzdem wirft es weiter die frage auf, wieso gelöschte artikel bei top of the shop weiter mitgezählt werden, denn das dürft irgendwo auch nicht korrekt sein, gelöscht ist gelöscht, auch wenns nur im admin geschieht.