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

См. посилання

Может кто поделится опытом.

Вы там уже сами ответили .
Для такой сборки нужно что-то уникальное от поставщика. Кроме его ID вряд ли что-то есть. Только складывать как числа нельзя, надо объединить как строки, например, что-то такое:
CONCAT(CAST(ид_поставщика AS CHAR), артикул)

Так нельзя делать ни в коем случае!!!

Ведь если у нас айд поставщика 1 и артикул 11, получим 111, а это равносильно 11+1=111=1+11. Ставал уже на такие грабли в подобном случае, правда там было айде склада + номер изделия по номенклатуре. Получали дубли через пару лет, это ненадёжно совсем.

Число нужно, потому что (поиск по числу можно индексировать и оно конечно должно бить уникальным)
ситуция: звонит чел и говорит артикул - вот для чего нужно число уникальное и максимально короткое.

Умнее чем табл. подстановки больше ничего не приходит в голову, я потому и ищу может что получше есть, думал про хеш, бейз64 и т.д., но опять-таки полученное число будет длинным, а это неудобно людям.

Ну поставьте разделитель ид и артикула и все будет уникально. Я просто пропустил.
CONCAT(CAST(ид_поставщика AS CHAR), CONCAT('-', артикул))

elosoft, первой мыслей было.) Но это уже будет не число, а строка со всеми последствиями, громадной потерей скорости поиска, ведь на строку если и навешать индекс, то тогда при большой БД на индексацию такого поля будет идти много ОЗУ. Конечно, в начале можно пренебречь этим фактором, но система делается как говорится - на века, халява не канает.)))

Но Вы не можете оперировать здесь непосредственно как числами. Уникальности точно не будет. У Вас всего 2 пути: либо использовать строки (со всеми последствиями ), либо написать функцию кодирования строки в уникальное число.

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

либо написать функцию кодирования строки в уникальное число.

Вот и мучаюсь какой же такой метод бы придумать или может есть.)

Ппутей на самом деле гораздо больше для такой задачи, скорее всего для поиска будет отдельный сервер, масштабировать можно всегда конечно, надо бы пивка попить на свежем воздухе, может что и придумаю, мож какой CRC32/SHA1 как вариант можно будет заюзать, правда опять таки вероятность колизий есть всегда, а это недопустимо в данном случае.

Кодировать то не проблема, а вот восстановить - это вопрос.

О, могу предложить вариант ограниченного использования .
Объединяем так id + '77777' + артикул
где 77777 - число, которое не может повториться ни в id ни в артикуле. В итоги получим число, которое можно преобразовать обратно в исходные числа.

А наперёд неизвестно какая солянка попадётся)

Лучше уж "-" вместо соли "77777"
Сами подумайте, вам будет удобно читать чтото вроде 1123227777723, я уже молчу чтоб запомнить если понадобится... 13 разрядов... многовато....)

Думал уже все повидал с БД, а тут оказалось что не все, бум думать.)

Ладно, думаю без подстановки не обойтись никак, поскольку проект в перспективе и веб-ориентирован, то там еще и URI надо сохранять, так что наверное вопрос закрыт, отдельный сервак на УРИ и на поиск, какогото монстра типа MSSQL 2008/Oracle 11g, есть сервак 16 ядерный с 32 Гб ОЗУ и будет пахать, если что то кластеров парочку приделаем, если конечно не сойду с ума, от шума этого вертольота. )

Я возможно не совсем понял задачу

но:
артикул1 = 100500
артикул2 = 256

артикул1*1000000 + артикул2 = 100500000256

артикул1 = отбрасываем_дробную_часть (100500000256 / 1000000) = 100500
артикул2 = 100500000256 - артикул1*1000000 = 256

Оно?

Можно предположить, что ID поставщика (фактически их количество) не больше, допустим, 100 000.
Тогда можно получать такое число: (id продукции) * 100 000 + (id прозводителя)
Как вариант: число Float, целая часть - производитель, дробная - продукция.

UPD:
Опередили

1. Операция умножения как и сумирования не гарантирует уникальность.
2. Перестановка местами обектов суммирования или умножения не даст тот же результат, что является колизией.
3. Получатся большущие числа, запоминать, произносить их не удобно.

Отпадает.

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

Можно предположить, что ID поставщика (фактически их количество) не больше, допустим, 100 000.
Тогда можно получать такое число: (id продукции) * 100 000 + (id прозводителя)
Как вариант: число Float, целая часть - производитель, дробная - продукция.

float - не точный тип, да и скорость работы с ними гораздо меньше чем с целочисленным, он никак не подходит, кроме того такой подход не даст возможности обратного декодирования, приведу пример: 1,3....*3=4, в обратку: 4/3=1,3Е, причем в 1,3Е могут попасть 4/3..3,1,... 3,3... и т.д.совсем не допустимо!

Идея SField и Onym возможно может дать хороший результат, если немного изменить.
Артикул может кончаться на 0 и поэтому его надо использовать в целой части. Для страховки 0 в начале артикула можно приписать в начало 1 (это если артикул может начинаться с 0). А в дробную часть вписать ID поставщика. Т.е. примерно так:
артикул + '.' + id
Это кстати сократит дробную часть.

ЗЫ Не видел предыдущего поста, так что возможно получился повтор .

По Вашему примеру:
производитель 1, товар 11: 11 * 1 000 000 + 1 = 11 000 001
производитель 11, товар 1: 1 * 1 000 000 + 11 = 1 000 011

Итого: Если хотя бы ID производителей отличаются, числа будут уникальными. Перестановка коллизий не дает.

Дробь использовать нельзя, дробь это всегда риск колизии, пример привёл.

Скажу проще, если в дробное поле записать 3,1, то это не значит что там именно 3,1, там чтото максимально близкое к 3,1, это может быть
3,1
3,100000000000001
3,100000000010002

и т.д.

Другой простой пример, опять-таки с области дискретной математики: сколько будет дробное:=1/0 ?...
А это будет "exp", несконченно большое число, при транслировании с СУБД - это будет макс. число дробного типа.)

А почему нельзя использовать два артикула?

id | url | артикул
fid | samsung | 100500
sid | fid | g600 | 21

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

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

3,1
3,100000000000001
3,100000000010002

А чё за база такая? Там будет хранится, больше 1 млрд моделей телефонов для каждой марки? Инопланетяни разработку заказали ?

А такой вопрос: артикул может начинаться с 0?