главной. ну пусть при желании найдет их но не на главной же))
Ты видел номенклатуру в 1С как забивают? По десятку одинаковых наименований с невидимыми идентификаторами.. Вот как в этом разбираться какая именно позиция тебе нужна?
да, гуид поможет юзеру)) посортируй по нему?
Что такое спецификация знаешь?
Часто ты сортируешь по id записи? И что это дает юзеру?
я знаю что пользователю рандомный набор знаков максимально неудобен. а прогеру - милое дело
Гуид ни чем не отличается для юзера от числа, как идентификатора записи
сейчас ковыряю бд оборудования. конечно там есть гуиды, но мне как пользователю они невсрались. хватает каталожных номеров
Пользователям явно краткий обучающий курс дают перед тем как за программу сажают в рабочем режиме - вряд ли юзер не понимает обозначения используемые
И? артикулы тоже есть и отображаются где нужно и поиск по ним тоже есть
Ген, к слову. Три-четыре числа ты запомнишь, 3-4 гуида/хэша - вряд ли
Ты точно с инженерным образованием?
А и не надо запоминать. В этом тоже есть своя фишка. Нет человеческой ошибки)
Док, вот возьми свою прогу.. Раздай 50-100 пользователям.. а потом попробуй их все данные слить в единую БД..
насколько я в курсе гуиды/хэши - ID чисто для машинного применения
Как и id записей
Коль, опять же, это лишь репликация, там гуиды оправданы
Так там у них она и используется в работе постоянно
гуиды вусть внутри сидят и наружу не вылазят
простой пример. Пока была svn-ная система хранения фпц/лазаря, легко было следить за версионностью. Как только перешли на хэше - капец
Гуиды и так не для юзеров. Гуиды тут отображаются как справочная информация. Юзеры могут по ним искать, но только если им нужно найти по гуиду
ты уж определись
Я тебе русским языком сказал, что это идентификатор элемента
Он же писал, что там сеть магазинов.. Объекты (элементы) создаются в разных филиалах, а используются потом по всей сети.. При наборе заказа сохраняются гуиды выбранных элементов.. я ж про спецификацию писал уже..
ага. Т.е. юзер ищет по артикулу, но артикул вида 72537526-ec8a-4e6c-9041-be09f6e26e20. Капец, удобно :)
Да ему пришла спецификация в электронном или бумажном виде - там пофигу что именно написано.. Главное, чтобы обозначения были уникальные
в электроннов - урл. в в бумажном штрихкод. с гуидами - не, спасибо
Не знаю, Коль. Можно запомнить цифр 9 знаков после запятой в числе Пи. Но вбивать гуиды при поиске - это за гранью добра и зла
А в урле будет тот же гуид забит? )) А размеры спецификации со штрих-кодами какие будут? А затраты на оборудование сканерами штрих-кодов? А точность чтения штрих-кодов?
Ген, это был сарказм. Артикул у товара, насколько я в курсе, тоже уникален. У тебя в софте, как я понял, товары отличаются названиями(но это неточно), артикулом и гуидом. Юзер для точного поиска пользуется гуидом. Теперь я не усну до утра :)
пусть. но я увижу чтото синенькое подчеркнутое и кликну
У товара артикул - не является уникальным идентификатором. Для разных магазинов артикул может быть разный, а товар один и тот же
Док, китайцы штампуют одни и те же товары и клеют разные маркировки для разных "поставщиков" - артикулы получаются разными.. но внешне и по характеристикам они ничем не отличаются
@HemulGM, сделай гуид синеньким ))
{C2D1C7F8-5754-8440-9157-62A0F9834502}
В общем, у изделий в чертежах есть конструкторское обозначение изделия.. Потом ещё есть публичные названия изделий, причём для разных потребителей эти названия могут отличаться.. Вот тут гуид работает в качестве конструкторского обозначения..
Это как раз понятно. Непонятно было, почему у Гены по гуидам товар ищется. Пока он не объяснил. Архитектура базы кривая такая 😁
Епрст. НЕ ТОВАР, А ЭЛЕМЕНТЫ
Ген, не заводись. Все уже выяснили. Сегодня выловил у себя чувствительный и неуловимый баг. Теперь спокойно иду спать 😊
И не самые лучшие. Например гуид нужно трансформировать для использования в качестве ид. Он растет/изменяется неправильно, для построения индекса.
Часто. У меня пользователи часто пользуются поиском по ID объекта. т.к. это способ однозначно идентифицировать. Коды у меня integer и пока не вылезли за миллион. ID контрагента, ID договора, ID печатной формы (из пары десятков выбрать). Мне катастрофически не хватает чего-то подобного в GooglePlay - куча софта с почти одинаковыми или вообще одинаковыми названиями, ID нет, URL нет, отличать только по иконке, да и то такое себе.. И как быть уверенным что я ставлю вот то что на соседнем телефоне?
Артикул товара может быть не уникальным даже у одного поставщика, а у разных - вообще без гарантий. Он обычно слишком короткий что бы быть уникальным. Но как способ отличить сходные товары - широко используется.
Расскажите подробней, плиз. Как трансформировать и как неправильно растет. Про такое не слышала
он вообще не растёт как выше подсказывают, для уникальности и упорядоченности лучше использовать составной ключ
Возможно имеется ввиду что-то другое
В google play у приложений есть id - он текстовый.
Ты что-то не то отвечаешь
Ну и как его увидеть на андроиде, в установленном приложении и в магазине приложений?
В гугл плей вроде никак))
Идеальный интерфейс :)
На сайте можно увидеть по ссылке или при помощи специальных приложений
Никак он нужен для уникальности приложения в магазине Только сам разработчик его видит
Возьмем пример ALTER TABLE locations ADD (uid_col RAW(32)); UPDATE locations SET uid_col = SYS_GUID(); SELECT location_id, uid_col FROM locations; LOCATION_ID UID_COL ----------- ---------------------------------------- 1000 7CD5B7769DF75CEFE034080020825436 1100 7CD5B7769DF85CEFE034080020825436 1200 7CD5B7769DF95CEFE034080020825436 1300 7CD5B7769DFA5CEFE034080020825436 Видишь, они изменяются в середине. При помещении в дерево индекса, они раскидаются в разные стороны. А если индекс будет еще и кластерным, в терминах некоторых БД, то прикинь, как их раскидает по ODS. А ведь это будут физические перемещения. В общем случае, guid - худший тип для кластерного индекса. SQL Server именно поэтому ввел специальный sequential GUID generator. NewSequentialId() А если GUID приходит с клиента, то беда встает в полный рост. Часто обсуждение GUID и ключей идет в контексте MSSQL потому что там это любят. 😊 SQL сервер сортирует значения uuid отличным от .net или Delphi способом. Сравнение ведется по байтовым группам справа-налево. Внутри байтовой группы сравнение ведется уже слева-направо. И вот так именно и должен трансформироваться GUID приходящий с клиента, и используемый в качестве строкового значения, а не встроенного серверного типа. https://habr.com/ru/companies/vk/articles/522094/ https://www.itshop.ru/GUID-v-roli-bystrogo-pervichnogo-klyucha-dlya-raznyh-BD/l9i29255 https://habr.com/ru/articles/665024/ https://habr.com/ru/articles/214667/ https://sqlchitchat.com/sqldev/tsql/guidinsqlserver/ https://dev-doc.blogspot.com/2014/09/ms-sql-guid-primary-key.html
Стикер
вот только генерация такого ID очень медленная. Где то читал статью со сравнением вставок с обычным целочисленным ID и последовательными guid, так последние в два раза медленнее. И поиск по такому индексу, даже если он некластерный, намного медленнее. И места больше съедает как поле, так и индекс, сравнительно с обычным.
В ссылках там есть в том числе сравнения и за и против. Предполагается, что есть веские причины использовать такие идентификаторы. Да чего уж, даже использование суррогатных ключей(id), в общем случае, тоже должно быть обосновано и не должно быть по-умолчанию. Если нет ни одного достойного кандидата на ключ... Н-р разные варианты guid хорошо себя показывают в распределенных системах.
Стикер
Составной ключ превращает FK в кошмар.
Мне нормально зашел как дополнительный ключ для слития в центральном офисе баз филиалов и рассылка им справочников)
Возможно лчше было бы иметь вместо этого в ключе id филиала
Хуже. Тоже пробовала, больше действий делать
Софтовая репликация штука интересная. Мультифазный коммит. Но это все по бедности/медленности каналов связи. Схемы шаблонные и описаны в проф-литературе. + Есть специальные решения - MasterData.
Обсуждают сегодня