Discussione: Integrità referenziale per la tabella post

Originariamente Scritto da jefferson

Buongiorno a tutti
dovrei eliminare circa 320.000 righe su un totale >3.000.000 dalla tabella post.
Si tratta del postumo di una importazione da phpbb effettuata alcuni anni fa.

Come posso fare per eliminare queste righe rispettando l'integrità referenziale dell'intero database?

Grazie

J.

Bella domanda!!
Bisognerebbe sapere quante e quali altre tabelle hanno campi in relazione con questi della tabella post



1. postid int 10 no Chiave primaria unsigned auto_increment
2. threadid int 10 no unsigned 0
3. parentid int 10 no unsigned 0
4. username varchar 100 no utf8_general_ci
5. userid int 10 no unsigned 0
6. title varchar 250 no utf8_general_ci
7. dateline int 10 no unsigned 0
8. pagetext mediumtext sì utf8_general_ci
9. allowsmilie smallint 6 no 0
10. showsignature smallint 6 no 0
11. ipaddress varchar 15 no utf8_general_ci
12. iconid smallint 5 no unsigned 0
13. visible smallint 6 no 0
14. attach smallint 5 no unsigned 0
15. infraction smallint 5 no unsigned 0
16. reportthreadid int 10 no unsigned 0
17. ame_flag tinyint 4 no 0
18. htmlstate enum('off','on','on_nl2br') no on_nl2br utf8_general_ci
19. amer_parsed tinyint 1 no 0

Originariamente Scritto da starlesseye

Bella domanda!!

Appunto! Per questo l'ho fatta!

Non sono riuscito a trovare uno schema relazionale che mi aiutasse... Ci sono sicuramente problemi di normalizzazione, FK, PK, ecc.

Originariamente Scritto da jefferson

Appunto! Per questo l'ho fatta!

Non sono riuscito a trovare uno schema relazionale che mi aiutasse... Ci sono sicuramente problemi di normalizzazione, FK, PK, ecc.

Avere lo schema relazionale del db del vbulletin significherebbe poterselo girare e trasformare a proprio piacimento.
Problemi di normalizzazione non credo e si nota a vista d'occhio che non ci sono ridondanze di dati e che le transitività fino alla terza forma funzionano a meraviglia.
é da almeno 3 settimane che cerco uno schema del db per capire anche i probemi che ha il mio vbulletin. Problemi creati non da vbulletin ma da un'upgrade un pò sfortunato.
Leggendo i dati nella tabella post ho l'impressione che sia stand alone e non si relazioni con altre. La mia è solo un'impressione non basata su verifica, ma penso che eliminando i tuoi post in eccedenza e ricostruendo gli indici non dovrebbe causare danni.
Ma aspetta che ti risponda qualche altro più esperto e conoscitore del VB di me

Originariamente Scritto da starlesseye

Avere lo schema relazionale del db del vbulletin significherebbe poterselo girare e trasformare a proprio piacimento.
Problemi di normalizzazione non credo e si nota a vista d'occhio che non ci sono ridondanze di dati e che le transitività fino alla terza forma funzionano a meraviglia.
é da almeno 3 settimane che cerco uno schema del db per capire anche i probemi che ha il mio vbulletin. Problemi creati non da vbulletin ma da un'upgrade un pò sfortunato.
Leggendo i dati nella tabella post ho l'impressione che sia stand alone e non si relazioni con altre. La mia è solo un'impressione non basata su verifica, ma penso che eliminando i tuoi post in eccedenza e ricostruendo gli indici non dovrebbe causare danni.
Ma aspetta che ti risponda qualche altro più esperto e conoscitore del VB di me

Nel file mysql-schema.php lo schema c'è, e anche le relazioni (quelle che si ricavano dalle PK-FK). Quindi non credo che ci siano segreti. Bisognerebbe però leggerlo e studiarlo riga per riga. Non c'è uno schema relazionale formalizzato.
Io invece proprio leggendo la tabella post credo che ci sia uno schema relazionale piuttosto rigido, ma controllato solo dal codice, e che non ci sia, almeno per com'è il database nella sua forma originale, nessuna possibilità di una cascade deletion automatica.
Credo che eliminando i post si creerebbero orfani, ma è proprio questo che mi interessava sapere.

Originariamente Scritto da jefferson

Nel file mysql-schema.php lo schema c'è, e anche le relazioni (quelle che si ricavano dalle PK-FK). Quindi non credo che ci siano segreti. Bisognerebbe però leggerlo e studiarlo riga per riga. Non c'è uno schema relazionale formalizzato.
Io invece proprio leggendo la tabella post credo che ci sia uno schema relazionale piuttosto rigido, ma controllato solo dal codice, e che non ci sia, almeno per com'è il database nella sua forma originale, nessuna possibilità di una cascade deletion automatica.
Credo che eliminando i post si creerebbero orfani, ma è proprio questo che mi interessava sapere.

La tua domanda è chiara.
Nel file schema ci sono le strutture delle tables ed io la vedo molto complicata estrarne uno schema concettuale per capire l'integrità referenziale.
Ragionandoci un pò su, anche a livello semplicistico, le foreign key chiave esterna servono a mettere in relazione tabelle. E fin qui ci siamo come da definizione. Ma guardando i campi (attributi) della table post se dovessimo cancellare un record (tupla) quali campi di altre tabelle resterebbero orfane?
KEY userid (userid, parentid),
KEY threadid (threadid, userid),
KEY threadid_visible_dateline (threadid, visible, dateline, userid, postid),
KEY dateline (dateline),
KEY ipaddress (ipaddress)
Quale altra tabella sarebbe orfana di queste FK della table POST?
Correggimi se sbaglio! Serve a ragionarci su.

Sì, estrarre uno 'schema concettuale' è parecchio difficile. Io ci ho provato con alcuni tools di RE (incluso MySQL Manager) ma senza successo. Ho anche chiesto nei forum istituzionali, nessuno mi ha saputo dire.

Ad ogni modo, a me risulta:
PRIMARY KEY (postid)
KEY userid (userid)
KEY threadid (threadid, userid)
FULLTEXT KEY title (title, pagetext)
Questo letto da mysql-schema.php, mentre leggendo la tabella ho anche un
KEY importpost_index (importpostid)
Quest'ultimo probabilmente ha a che fare con l'importazione da phpbb, ma la persona che se ne occupava non c'è più e quindi non ho dettagli.

Essendo postid una chiave primaria, ci sono naturalmente diverse tabelle che la usano come FK:
attachment
discussion
editlog
infraction
moderatorlog
podcastitem
postedhistory
postindex
postlog
postparsed
posthash
reputation
ecc. ecc.
Questo significa che per ogni tupla di post dovrei andare a cancellare anche i record che contengono postid come FK o che la relazionano. E per ogni record di ogni tabella che ha una FK (postid) rifare la stessa operazione e ritroso sulle equivalenti rispettive PK.
O sbaglio?
Se non sbaglio, cancellare le righe da post è un gran mal di testa.

Originariamente Scritto da jefferson

Sì, estrarre uno 'schema concettuale' è parecchio difficile. Io ci ho provato con alcuni tools di RE (incluso MySQL Manager) ma senza successo. Ho anche chiesto nei forum istituzionali, nessuno mi ha saputo dire.

Ad ogni modo, a me risulta:
PRIMARY KEY (postid)
KEY userid (userid)
KEY threadid (threadid, userid)
FULLTEXT KEY title (title, pagetext)
Questo letto da mysql-schema.php, mentre leggendo la tabella ho anche un
KEY importpost_index (importpostid)
Quest'ultimo probabilmente ha a che fare con l'importazione da phpbb, ma la persona che se ne occupava non c'è più e quindi non ho dettagli.

Essendo postid una chiave primaria, ci sono naturalmente diverse tabelle che la usano come FK:
attachment
discussion
editlog
infraction
moderatorlog
podcastitem
postedhistory
postindex
postlog
postparsed
posthash
reputation
ecc. ecc.
Questo significa che per ogni tupla di post dovrei andare a cancellare anche i record che contengono postid come FK o che la relazionano. E per ogni record di ogni tabella che ha una FK (postid) rifare la stessa operazione e ritroso sulle equivalenti rispettive PK.
O sbaglio?
Se non sbaglio, cancellare le righe da post è un gran mal di testa.

A quanto pare dipende dalla versione del vb e sopratutto dai plugins istallati.
Non resta che capire cosa fa la routine che cancella un post e forse non basta.
E' vero che ricavare a ritroso uno schema concettuale che utilizza 200-300 tabelle è un'impresa mostruosa, per questo dicevo che conoscerlo ti permetterebbe di rivoltare i vb come ti pare e piace, anche pechè vb non è database didattico in quanto incorpora molte cose che uno pensa siano facilmente e chiaramente visibili nei sorgenti
Chissà se Knut, Morrison, Pratt lo sapevano e sopratutto se ne hanno mai parlato con Codd

PS: queste due tabelle che usano il postid come chiave esterna incutono timore
postparsed
posthash

Hai provato a leggerti il tools.php che sta nella cartella No_upload? magari ti da qualche indicazione nel caso riparasse indici di tabelle

Originariamente Scritto da starlesseye

A quanto pare dipende dalla versione del vb e sopratutto dai plugins istallati.
Non resta che capire cosa fa la routine che cancella un post e forse non basta.
E' vero che ricavare a ritroso uno schema concettuale che utilizza 200-300 tabelle è un'impresa mostruosa, per questo dicevo che conoscerlo ti permetterebbe di rivoltare i vb come ti pare e piace, anche pechè vb non è database didattico in quanto incorpora molte cose che uno pensa siano facilmente e chiaramente visibili nei sorgenti
Chissà se Knut, Morrison, Pratt lo sapevano e sopratutto se ne hanno mai parlato con Codd

PS: queste due tabelle che usano il postid come chiave esterna incutono timore
postparsed
posthash

Hai provato a leggerti il tools.php che sta nella cartella No_upload? magari ti da qualche indicazione nel caso riparasse indici di tabelle

Ciao. Ho provato a cercare in rete: altri utenti prima di me hanno avuto lo stesso problema, ma non ho trovato soluzioni.
Ho provato anche, come intelligentemente dici tu, di capire cosa fa editpost.php, che alla fine è il codice che cancella fisicamente il post, ma non ci ho capito nulla, è molto complesso perchè gestisce anche i permessi, ecc. E questo conferma che una semplice query DELETE non può funzionare. Le mie conocenze di php sono pressochè a zero.

Però ho visto che nel ACP c'è una opzione per cancellare tutti i post di un certo utente. Allora pensavo di creare un utente fittizio, modificare con SQL userid da tutti i record duplicati (che sono noti) della tabella post mettendoci l'id dell'utente fittizio, e poi far cancellare da ACP i post dell'utente fittizio.

Pensi che possa funzionare? Dopotutto all'integrità riferenziale ci dovrebbe pensare ACP

Originariamente Scritto da jefferson

Ciao. Ho provato a cercare in rete: altri utenti prima di me hanno avuto lo stesso problema, ma non ho trovato soluzioni.
Ho provato anche, come intelligentemente dici tu, di capire cosa fa editpost.php, che alla fine è il codice che cancella fisicamente il post, ma non ci ho capito nulla, è molto complesso perchè gestisce anche i permessi, ecc. E questo conferma che una semplice query DELETE non può funzionare. Le mie conocenze di php sono pressochè a zero.

Però ho visto che nel ACP c'è una opzione per cancellare tutti i post di un certo utente. Allora pensavo di creare un utente fittizio, modificare con SQL userid da tutti i record duplicati (che sono noti) della tabella post mettendoci l'id dell'utente fittizio, e poi far cancellare da ACP i post dell'utente fittizio.

Pensi che possa funzionare? Dopotutto all'integrità riferenziale ci dovrebbe pensare ACP

E come mi ha detto un grande di questo forum fatti prima un backup della tabella post e magari, visto che conosci ormai tutte le fk anche delle tabelle relative.

Mi piacerebbe aiutarti, ma non sono la persona più adatta, sono un newbie del vbulletin e mi caricherei di troppe responsabilità.
Sicuramente ogni CALL() dell'acp pensa all'integrità, sarebbe assurdo se non lo facesse, ad ogni reindex salterebbe il DB.
In pratica stai dicendo "Se cambio id a tutti i post raddoppiati associandoli a quello dell'iduser fittizio, al massimo se mi va male uccido un fittizio"
Non lo so!! Mi sembra troppo immediata come soluzione.
Ma sei sicuro che nell'acp non ci sia un remove di tutti i post raddoppiati? A me sembra di averlo visto da qualche parte.