Witam.

Szukam jakiegoś dobrego sposobu na rozwiązanie problemu nakładających się identyfikatorów.

Mam w pierwszym systemie dwie tabele, których odpowiednikiem w drugim systemie jest jedna tabela. Problem w tym, że identyfikatory w pierwszego systemu sa przekazywane do mnie poprzez XML i każda z tych tabel daje swoje własne nie patrząc na drugą tabelę. Te niekiedy się nakładają i teraz nie wiem, jak najsensowniej (i najwydajniej) zniwelować te różnice.

Przykład:

Dostaję:

[XML] pobierz, plaintext 
<category id="1">nazwa</category>
<kind id="1">jakaś inna nazwa</kind>
[XML] pobierz, plaintext 

i chcę to umieścić w jednej tabeli u siebie i zachowac możliwość odtworzenia relacji. Gdyby id były tu unikalne, to nie byłoby problemu, bo wystarczyłaby zwykła tabela z relacjami.

Jeśli ktoś ma jakiś pomysł, to będę wdzięczny za pomoc.

Pozdrawiam.

Do końca chyba nie rozumiem problemu. Dlaczego nie zrobisz w tej tabeli dwóch kolumn categoryId i kindId?

Nie chodzi o samo przechowywanie, tylko o relację.
Uściślę.
W sklepie mam kategorie, natomiast hurtownia, z którą się łącze i z której pobieram dane ma taką dziwną strukturę, że ma i kategorie i typy. To, co jest u nich typem u mniej jest też kategorią. Piszę aplikcję tak, aby obsługa tego była przezroczysta. Problemem jest zachowanie relacji, takiej, że ID mojej kategorii odpowiada ID ich kategorii/typu.

Pozdrawiam i dzięki za zainteresowanie.

Unikalność masz na dwóch kolumnach. Jedna będzie null, druga nie.

id_kategoria, id_kategoria_hurtowania, id_typ_hurtowania

Ok sf, ale wydaje mi się, że problem z relacjami nie znika całkowicie. Bo pozostaje problem produktu który u Cysiaczka prawdopodobnie posiada ID kategorii, i jakoś musi pogodzić ze sobą mimo wszystko dwa takie same ID (to że przechowywane są w oddzielnych kolumnach niewiele daje). Wydaje mi się, że obowiązkowo produkt powinien mieć pole rozdzielające z jakiego rodzaju kategori (czy category czy kind) pochodzi. (Jeśli oczywiście rozumiem własciwie problem Cysiaczka)

Tak samo więc tabela kategorii nie musiałaby mieć dwóch kolumn odpowiadających za ID, tylko jedną nieunikalną ID i dodatkowo drugą przechowująca informację czy jest typu kind czy category. W innym wypadku faktycznie, relacje lecą "na łeb, na szyję"...

Wprowadzane produkty będą powiązanie relacją z nowymi kategoriami, a te stare kategorie/typy są tylko używane przy imporcie. Możecie mi przedstawić problem na sensownym przykładzie jakiej operacji nie będzie można przeprowadzić?

Oczywiście można sobie stworzyć jedną unikalną kolumnę - budowaną na bazie np. md5, ale przy tylko dwóch parametrach wydaje mi się, że nie ma takiej potrzeby.

Nie jestem dobry w przykładach, więc przedstawię to łopatologicznie.

Importujesz kategorie (w sensie, jednocześnie category i kind). Chcesz dodać produkt posiadający jedną kolumnę category_id. Niewiele zmieni to, że w tabeli kategorii ID kind i category są w oddzielnych unikatowych kolumnach tabeli. Produkt dalej odnosi się do tylko i wyłącznie jednej wartości, a ta może występować podwójnie. I tutaj leży właśnie (tak mi się wydaje) problem.

Dodanie do produktu pola odpowiadającego za identyfikowanie kategorii (zawierające czysto przykładowo wartości: kind lub category) i takiego samego w tabeli odpowiadającej za kategorię rozwiązałoby to częściowo ten problem, ale jakoś nie widzi mi się to rozwiązanie jako wyjątkowo optymalne.


Edit:

Właśnie chodzi mi o sposób powiązania produktu z kategorią. Bo wg. czego przypiszesz produkt posiadając w bazie powtarzające się identyfikatory? Potrzebne jest coś co rozgraniczy powtarzające się wartości. Nawet coś takiego jak zapisywanie identyfikatorów kategorii w sposób: c40, c42, c47, c80, k39, k40, k41 (w zależności od kind / category )

Jutro Wam powiem, czego dokładnie nie da się zrobić, bo faktycznie się nie da - muszę tylko to ubrać w jakiś przykład :|
@Nattfarinn masz bardzo dużo racji.

Pozdrawiam.