Wenn Du mit
SQL danach suchen musst, dann lieber als integer, diese Datentyp kann vom Datenbank-Server besser indixiert und somit durchsucht werden.
Ein String ist da immer langsammer.
Entschuldigung, das ist viertrangig. Was heißt überhaupt 'besser indexiert'? Willst Du im Ernst behaupten, das Du einen Unterschied messen kannst, zwischen einer Zahl und einem varchar(10) Datentyp? Wir leben im Jahr 2015, da ist das so was von egal.
Kurz geschätzt: Ein B-Baum hat bei 100 Mio Einträgen und einem 100er key bei einer Seitgröße von 8k eine Tiefe von ca. 5 Ebenen. In jedem Blatt sind ca. 60 Keys gespeichert. Ich bin nach ca. 40 Vergleichen am Ziel (5x Binärsuche in einer Liste mit 60 Schlüsseln).
Ein B-Baum mit einem INT- Key hat eine Tiefe von ca. 3 Ebenen, bei vielleicht 1000 Keys pro Seite/Blatt. Das sind dann 30 Vergleiche.
(Hoffentlich habe ich mich nicht komplett verrechnet)
Wer Artikelnummern als Zahl anlegt, der macht einen riesen Fehler. Spätestens Übermorgen soll doch eh umgestellt werden (Murphy rules).
Ich hatte erst 7-Stellige (bei einem DAX-Unternehmen), dann 8, aber immer numerisch. Und dann -letztendlich- doch fast numerisch. Also 12 der 14 Stellen waren schon Ziffern. Nur die blöden Verpackungscodes in der Mitte nicht. Mist.
Leg das als char/varchar(X) an, wobei X noch ein wenig Luft nach oben lässt (nun aber nicht 1000 oder so). Dann bist Du auf der sicheren Seite. Und ignoriere die premature Optimization Profis.