Поставщики + артикулы = общий артикул

Цитата ("MMM_Corp"):

Получатся большущие числа, запоминать, произносить их не удобно.

Делайте как нормальные сайты, не ломайте себе моск:

посилання
посилання
посилання

Давно сами вводили что-то длинее: посилання ? ))

SField, не могу сказать, привел сравнение для понятия, но данных будет очень много.) Я не спрашиваю, мне платят и больше носа не сую никуда.)

Могу сказать одно, представьте себе чтото вроде БД википедии где каждую сек. данные страницы меняются по 10000 и более раз в сек. и вся история сохраняется, а размер страницы порядка 10 мб, примерно так.
Это не фантастика, подобные разработки делаются в высокоточной биомеханике, или как оно там называется по научному, напр. взять тот же ген. код, и розложить его на атомы, потом все это сканить всего 1 сек. сколько молекул там изменится... Очень много, такие системы существуют и поток данных не сравнимы с тем же ютубом напр.) Да я бы запросто с инопланетянами поработал, вот только они никак не могут понять что такое СБС, сразу башка взрывается... Пунктик у них такой. )))))

elosoft, нет, все артикулы являются целими числами от единицы до хз скоко как много, пока сервак не лопнет, поэтому и сервак был предоставлен с громадным запасом.

SField, я не делаю сайты.)))
Да выводил) еще в 2004 году, ФИО чела, идент. код, номер счета.)

При больших данных, просто большее кол-во идентификаторов:

cpu = № процессора
core = № ядра
tick = процессорный тик
time = полное время = 10:10:11'100
mid = id молекулы
aid = id атома
it = итерация
и т.д.
inf = служебная информация

если бы передо мной стояла подобная задача, я бы не мудрил, чем проще, тем лучше. Тем более, что под задачи вроде биомеханики и записи млрд данных в секунду пишутся свои базы данных, и используются не такие скудные ресурсы как выделили Вам

В любом случае, отпишите о решении задачи. Интересно на чем остановитесь.

А откуда берется список артикулов?
Если сами их генерите, то это одно, но если берете артикулы от производителя, то... я бы не закладывался на то, что артикул — это именно цифра. Это сейчас у Вас только цифры, а завтра может добавиться буквенный артикул, или артикул с пробелами, черточками, и т.д.

И еще, я бы не закладывался, что артикул будет уникальным для производителя. Товар может отличаться еще и номером серии, кодом поставки (например региональным) и т.д., но артикул производитель может один и тот же оставить. К примеру, у Вас есть две мобилки одного и того же типа, но одна идет с русской прошивкой, а другая — с немецкой прошивкой... артикул будет разный или нет? Может быть, конечно, и разный, но очень вероятно, что и один и тот же... А ведь это как бы уже совсем разные товары, для разных категорий пользователей.

В общем, дело, конечно, Ваше.
Я бы оставил отдельные поля — числовое "код производителя" и символьное "артикул", с возможностью поиска по ним.
Символьное — потому что даже если сейчас у Вас все артикулы числовые, все равно возможно что первая цифра будет 0, и тогда, если хранить это в числовом поле, то этот 0 будет утерян.
И только если артикул — всегда число, которое не начинается с нуля, и не может быть длинным (а то вдруг попадется артикул длиной 25 цифр?), то тогда можно хранить его в поле числового типа.

А в базе данных бы типы товаров идентифицировал по суррогатному ключу типа INTEGER (например автоинкрементному, или сгенерированному по какому-то принципу).

Цитата ("tvv"):

tvv

, артикули у поставщиков строго определенны, все одинаковы для всех, все строго начинаются от 1, только цифры, любая малейшая модификация идет как отдельная сущность, назвав артикул вам не привезут мобилу с немецкой прошивкой, у нее будет другой артикул, это полностью исключено. Сравнение с мобилками и поставщика только для примера.

Цитата ("tvv"):

А в базе данных бы типы товаров идентифицировал по суррогатному ключу типа INTEGER (например автоинкрементному, или сгенерированному по какому-то принципу).

Ну дик... , вторую страницу расписываю что ищу метод создания чегото вроде безколизийного слепка в виде цифр. с обраткой, но я не настолько искусный в математике.)

Повторюсь, есть 2 поля, артикул (целое число от 0 до хз скоко) и код поставщика (айдешка, фуковки в общем все что угодно), это все что в БД будет дейсвтительно уникальным и не повторимим, БД будет представлять собой сервер, к которому будут идти репликации, ручные вигрузки, может раз в день, может раз в год, может в реальном времени... черт его знает,.. будут всякые,...и другие синхронизации, поэтому полагатся на автоинкремент не получится, если айдешка ун. товара по одной базе одно число, то маловероятно что на другой базе оно будет такимже, но... для быстрого востановления истины нужен процесс, который обеспечит быстрый поиск и "репликатность" данных, Batch Move полагаясь на 1 уникальный признак. Ситуация конечно ерундовая, но единого сервера не будет и боюсь ошибится. Важнейшим критерием выступает - скорость поиска по артикулу, вот чего я вожусь с тем чтобы обеспечить в базе уникальный артикул-индекс.

Ладно, всем спасибо. Буду дальше думать над траблой. Пока самый простой и надёжный вариант - таблица подстановки, не нравится оно мне всеравно(.