relációs adatbázis mestereknek: leíró mezőből elsődleges kulcs

Természetesen nem az OTP-ről van szó, hanem egy hipotetikus bankról, ahol az internetes hozzáféréshez volt egy technikai azonosító (nem azonos a számlaszámmal) meg egy jelszó. Volt még leíró adatként telefonszám és emailcím is. Na, jött Agilis Antal, és úgy döntött, hogy a telefonszám és az emailcím lesz elsődleges kulcs (megjegyzés: van, akinek már a 'két elsődleges kulcs' intézménye sem tetszik). És akkor a kérdés: mi lesz azzal a userrel, aki több számlával zsonglőrözött azonos emailcímmel és telefonszámmal?

Az ráfarag. (Ezt már a "Body" részbe írtam, de gondolom, mindenki magától is kitalálta.)

( SkyNET | 2025. 11. 17., h – 21:39 )

Ha az azonosítók átszervezése előtti korszakban volt ennél a hipotetikus banknál két számlád, akkor azokhoz két, egymástól teljesen független internetbanki hozzáférés tartozott? Mintha nem is egy ügyfélhez kapcsolódnának? 

Igen, az internetes elérés a számlához tartozott, illetve azon belül is a számlatulajdonoshoz, tehát ha két számlatulajdonos volt (tipikusan férj+feleség), akkor két internetelérést lehetett csinálni (például a bankkártyák kezeléséhez, hiszen az is specifikusan a számlatulajdonoshoz tartozik.)

( Friczy v | 2025. 11. 17., h – 23:02 )

Agilis Antal szimplán hülye. Eleve - persze számlatípustól függően - egy ügyfélnek helyből lehet egy banknál több számlája, nem kell ehhez zsonglőrködni, tehát itt igazából csak ügyfélazonosító kéne legyen. A bank pedig nem igazán követelheti meg az ügyféltől, hogy legyen neki telefonszáma és/vagy email címe.

A számlához valóban nem "must have" egy mobilszám, de a kötelező 2FA okán, aminél az SMS a fallback, szükséges, hogy legyen. 
Az, hogy több számlához ugyanaz a mobilszám tartozik, nem ördögtől való - ugyanis az az ügyfélhez köthető adat, nem a számlához/szerződéshez. ügyfél - mobilszám is lehet bőven 1:n reláció, ahogy az üf - számla is 1:n. Ebből adódóan kell(ene) egy olyan összerendelés is, ahol az adott számlához hozzárendelheti az üf. a mobilszámai közül az egyiket. Ez persze a nagyon perverz corner case-esk egyike, hogy Gipsz Jakabnak van három számlaszerződése meg négy mobilszáma, és minden szerződéshez más-más mobilszámot  szeretne használni. 

Ha jó az üf.törzs, akkor az egy üf - több mobilszám, több e-mail cím nem kell, hogy gondot okozzon - ehhez persze az is szükséges, hogy Gipsz Jakab három szerződéséhez ne három identitás tartozzon az ügyféltörzsben, csak egy... És akkor már lehet a Gipsz Jakab üf.-nek egy kijelölt elsődleges mobilszáma, ami egyedi az üf.törzsön belül, és lehet n darab másik, ami meg "közös" Gipsz Jakab és Gipszné Cement Etelka esetén. 
 

( hunludvig v | 2025. 11. 18., k – 08:29 )

Itt egy Agilis Antal beszél, aki egy "UNIQUE CONSTRAINT" oda.. implementálása előtt, azért lefuttat egy "GROUP BY HAVING count(1)>1"-et, de sajnos látja, hogy ez nem magától értetődő, akár a saját csapatában sem. :(

Én azt figyeltem meg, hogy a lelkes fiatalok legjobban nulláról kezdeni szeretnek, mivel látják, hogy a régi program bonyolult. A végére persze megértik, hogy a program azért bonyolult, mert a feladat bonyolult, de akkora már mások lesznek a lelkes fiatalok.

(Joel Spolsky meg nyilván a lengyel miniszterelnök, vagy ilyesmi.)

Szerintem ez a Waterfall sosem volt valóság, mindig is csak szalmabáb volt. Ahogy én látom a szoftver-fejlesztés mindig try-and-fault módszerrel történt, mert az egész csődtömeg [értsd: fejlett eszközrendszer] nemcsak tele van problémákkal, de folyamatosan változik is. Ugyanez igaz a megoldandó feladatra is: Agilis Anti már 99%-ra készen van, amikor meghallja, hogy van olyan lakossági bankszámla, aminek két számlatulajdonosa van, tehát néhány alapelv, amire várat épített, megdőlt.

( gelei v | 2025. 11. 18., k – 08:51 )

A meg nem nevezett bankról nem tudok nyilatkozni, de az OTP-nél ez például úgy volt emlékeim szerint, hogy egy teljesen új regisztrációt kellett csinálni, ahol az email volt a usernév. Ha jól rémlik, ők nem a meglevő adatbázisból forgatták át az emaileket, hanem egy teljesen új auth rendszer került az új netbank elé.

A meg nem nevezett OTP-nek van egy olyan menüpontja a régi rendszerben, hogy előrelépés az új rendszerbe.
Megadod a telefonszámot/emailcímet, és ő átmigrálja az újba renszerbe a régiből valamelyiket azok közül, amihez ez a telefonszám/email volt beállítva.
Persze aki okos, az még ezelőtt megváltoztatja a telefonszámot a régi rendszerben. Ja nem, a biztonsági telefonszámot megváltotatni csak személyesen lehet.

Én ilyen migrációs akármit nem csináltam, talán anno nem is volt, csak végignyomkodtam a hivatalos regisztrációs formot.

ő átmigrálja az újba renszerbe a régiből valamelyiket azok közül, amihez ez a telefonszám/email volt beállítva.

Ezt nem értem. Ha már be vagy lépve a régi rendszerbe, ott már megvan, hogy melyik userrel vagy bent. Nem azt migrálja, hanem random választ egy másikat?

( kicca | 2025. 11. 18., k – 08:54 )

OTP mindig is fura volt. Hozzam tartozott 2-3 user. Elegge hetkoznapi nevem van. Igy ennek a 2-3 usernek mindig megkaptam az ertesiteseit, stb. Panasszal eltem, hogy ez igy nem lesz jo, de azt mondtak nem latnak semmit, nincs gond. Utana is kaptam az ertesiteseiket. Azota mar nincs OTP szamlam, de meg mindig kapom, ha valaki regisztral ugyan ilyen nevvel vagy hasonlo email cimmel. vagy nem tudom mi kell hozza, de meg mindig jon fel-1 evente ilyen uzenet. Mar panasznak vegkepp nincs ertelme, mert nem vagyok ugyfeluk es igy vegkepp nem tudnak tenni semmit.

Nekem is gyakori nevem van, az email címem is elég egyértelmű, rendszeresen kapok mindenhonnan is értesítéseket, amik nem nekem jönnek. A megoldás nagyon egyszerű; az emberek egyszerűen a saját email címüket sem tudják, vagy akinek bediktálják az nem rögzíti rendesen. Pl. kispista123@...-ból lesz kispista@...

Nem szól, mert ugye lehet ugyanaz az email címed több számlához is, vagy lehet, hogy mondjuk egy közös email címet adsz meg. Mivel korábban az email nem volt egyedi azonosító adat, így check sincsen rá valószínűleg.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Néhány nem neked szóló értesítéssel jelezd a bank DPO-ja felé, vagy durvábban a NAIH felé... Írásban. Ez hatásos tud lenni. Főleg az utóbbi... (De az előbbi is, ha hozzáteszed, hogy a NAIH felé történő jelzéssel is élni fogsz a probléma további fennállása esetén. Az, hogy nem vagy üf. az pláne problémás...)

( gelei v | 2025. 11. 18., k – 08:54 )

És akkor a kérdés: mi lesz azzal a userrel, aki több számlával zsonglőrözött azonos emailcímmel és telefonszámmal?

Ha Digitális Szolgáltatási Szerződést köt, lesz egy saját felhasználói profilja, amibe automatikusan bekerül az összes olyan számla, amit kezelhet.

A „saját” profiljába kerülnek például azok a bankszámlák, amiknek Ön a tulajdonosa, valamint a hitelkártya számláit is itt kezelheti. De ha például állandó meghatalmazott, törvényes képviselő vagy gondnok egy számlán, akkor azok külön profilba kerülnek. Ha például 2 másik ügyfél egy-egy számláján törvényes képviselő, akkor a saját profilján túl további 2 profilja is lesz.

Van számlatulajdonos, ami egy lehet a számlánál, és van rendelkezési jog, ami "ráakasztható" a számlára, egy másik létező üf. entitás számára. Legalábbis jobb helyen ez van, azaz ha te vagy Gipsz Jakab, és van teljes és önálló rendelkezési jogod Cement Etelka számláján, akkor a netbank/mobilbank felületen bejelentkezve mindkettőt látnod kéne. Legalábbis az user igény ez lenne, ha jól gondolom. 

( asch v | 2025. 11. 18., k – 11:16 )

Lesz még olyan is aki a felesége/fia/szomszédja emailjével regisztrált, mert neki olyanja nincs és azt se tudja mi az.

És ugyanez telefonszámmal. Nagyon kényelmes azt feltételezni, hogy "hát 2025-ben mindenkinek van már telefonszáma, ugye? UGYE?!" de hát a Ügyfélkapu+/DÁP ügy is megmutatta, hogy azért ez ennyire nem egyszerű eset.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-