Oracle PL/SQL generator NIP oraz REGON

0

Witam potrzebuje stworzyć w Oracle PL/SQL (SQL Developer) funkcji/procedury która będzie generowała NIP oraz REGON tylko nie bardzo wiem od czego mam zacząć i jakby to miało wyglądać dlatego piszę o poradę :/ na internecie niestety nie mogę znaleźć gotowego skryptu dzięki któremu mógłbym stworzyć jakoś po swojemu/podpatrzeć i się poduczyć :D

2
  1. REGON/NIP mają określone formaty - <wartości> + cyfra kontrolna
  2. Generujesz tyle losowych cyfr ile potrzeba i wyliczasz cyfrę kontrolną, sklejasz i masz gotowe
  3. Jak generować losową liczbę w PL/SQLu? Pakiet DBMS_RANDOM
1

Ale na podstawie czego i po co chcesz generować ten nip i regon? Może chodzi ci o walidację: http://kszpyt.blogspot.com/2011/03/walidacja-nip-pesel-i-regon-im-mniej.html

Możesz też generować przypadkowy ciąg i weryfikować czy waliduje się jako poprawny NIP lub REGON.

0
Tomek Pycia napisał(a):

Ale na podstawie czego i po co chcesz generować ten nip i regon? Może chodzi ci o walidację: http://kszpyt.blogspot.com/2011/03/walidacja-nip-pesel-i-regon-im-mniej.html

Możesz też generować przypadkowy ciąg i weryfikować czy waliduje się jako poprawny NIP lub REGON.

O właśnie o to to chodzi , w sensie generuje losowy ciąg i sprawdzam czy identyfikuje się jako poprawny NIP lub REGON

0

Numerów się nie losuje tylko tworzy wg algorytmów je definiujących. W najgorszym przypadku możesz nigdy nie wylosować poprawnego numeru i co wtedy?
Tu np. masz opisy http://www.algorytm.org/numery-identyfikacyjne/

1
robertos7778 napisał(a):

Numerów się nie losuje tylko tworzy wg algorytmów je definiujących. W najgorszym przypadku możesz nigdy nie wylosować poprawnego numeru i co wtedy?
Tu np. masz opisy http://www.algorytm.org/numery-identyfikacyjne/

od tego jest walidator :)

Trochę mi tu zajęło ale proszę może komuś się przyda !! Generator Regonu

CREATE OR REPLACE PROCEDURE REGON_GENERATE
IS
    TYPE T_REG IS TABLE OF NUMBER;
    COL_REG T_REG;
    V_CLIENT_REG VARCHAR2 (9) DEFAULT '';
    V_NUMBER INT := 0;
    V_NUMBER2 INT :=0;
BEGIN
    COL_REG := T_REG();
    FOR i IN 1..9 LOOP
            COL_REG.EXTEND;
    END LOOP;
    V_NUMBER := 10;
    WHILE V_NUMBER = 10 
    LOOP
    V_CLIENT_REG := '';
        FOR i IN 1..8 LOOP
            COL_REG(i) := TRUNC(DBMS_RANDOM.VALUE(0,9));
            V_CLIENT_REG := V_CLIENT_REG||COL_REG(i);
        END LOOP;
        V_NUMBER2 := 8*COL_REG(1) + 9*COL_REG(2) + 2*COL_REG(3) + 3*COL_REG(4) + 4*COL_REG(5) + 5*COL_REG(6) + 6*COL_REG(7) + 7*COL_REG(8);
        V_NUMBER := mod(V_NUMBER2,11); 
        IF V_NUMBER = 10 
        THEN
        V_NUMBER :=0;
        END IF;
            SELECT COUNT(*) INTO V_NUMBER2 
            FROM clients
            WHERE REGON = V_CLIENT_REG||V_NUMBER;
            IF V_NUMBER2 > 0 
            THEN
            v_number :=10;
        END IF;
    END LOOP;
    COL_REG(9):=V_NUMBER;
    V_CLIENT_REG := V_CLIENT_REG||COL_REG(9);
    DBMS_OUTPUT.PUT_LINE('REGON: '||V_CLIENT_REG);
COMMIT;
EXCEPTION WHEN OTHERS
THEN
ROLLBACK;
RAISE;
END;

0

No i ładnie, losujesz tylko fragment. Bo się obawiałem, że zachcesz losować całość i sprawdzać czy pasuje :)

1

@jelon512: +1 za to, że przychodzisz z rozwiązaniem własnego problemu. Potraktuje poniższe jako konstruktywną krytykę ;)

  • Nie widzę sensu umieszczania w procedurze commita i rollbacka, jako, że nie wykonujesz żadnej transakcji. W jeśli wywołasz tę procedurę w ramach jakiejś istniejącej transakcji, to efekty mogą być opłakane.
  • Nie sądzisz, że funkcja byłaby bardziej pragmatycznym rozwiązaniem? Tj. zamiast drukowania na standardowe wyjście, to może po prostu zwracać wygenerowany regon? Wówczas masz wygenerowany regon i możesz coś na nim zrobić, np. wywołać na nim inną funkcję PL/SQL, albo użyć funkcji generującej regon w zapytaniu SQL.
  • Łączenie sprawdzania unikalności i generowania regonu, może da się obronić, ale można to rozbić na dwie mniejsze funkcje: 1. - generuje regon, 2. - sprawdza unikalność
  • Zapewnienie unikalności - w tej implementacji polegasz na optymizmie, tj. zakładasz po cichu, że istniejące dane nie zostaną zmodyfikowane przez współbieżne transakcje. Nie musi to być prawda, tak samo, jak założenie, że będą współbieżne transakcje ;) Z praktycznego punktu widzenia zapewnienie "prawdziwej" unikalność jest troszkę bardziej złożone.
  • Dla porządku, są też regony 14-cyfrowe. Może potrzebujesz taki przypadek uwzględnić, może nie.

Ja bym ten Twój kod trochę przerobił i starał ponazywać zmienne jakoś po ludzku: http://sqlfiddle.com/#!4/664b96/1

1 użytkowników online, w tym zalogowanych: 0, gości: 1