[Проектирование БД] id как идентификатор клиента?
Что-то мне подсказывает, что обычно делают не так.Что?
Я подозреваю, что персональный номер на моей карточке Много.ру не является первичным ключем или генерируется не подряд.
> Пока я знаю (понял) следующие соображения:
если номер создается последовательно, то можно аттаковать соседей (от имени соседа произвести какие-то действия)
если id публичный, то в него стоит включать контрольную сумму - это защищает от фальсификации id-а (как целенаправленной, так и по забывчивости)
если номер создается последовательно, то можно аттаковать соседей (от имени соседа произвести какие-то действия)
если id публичный, то в него стоит включать контрольную сумму - это защищает от фальсификации id-а (как целенаправленной, так и по забывчивости)
Если не хочешь светить код клиента, заведи еще буквенный идентификатор и показывай его в интерфейсе или печатных формах.
---
А у тебя только физ лица или юр лица тоже есть?
---
А у тебя только физ лица или юр лица тоже есть?
Есть ситуации, когда код должен генериться рандомно.
Да тот же id сессии, к примеру (чтобы нельзя было подобрать другой существующий id, как сказал ).
В случае id пользователя, в большинстве случаев, такой проблемы нет, т.к. подменить id всё равно нельзя (а там, где реально - это не принесёт подменившему никакой пользы, ссзб и пользы от знания ещё чьего-нибудь id не будет.
Да тот же id сессии, к примеру (чтобы нельзя было подобрать другой существующий id, как сказал ).
В случае id пользователя, в большинстве случаев, такой проблемы нет, т.к. подменить id всё равно нельзя (а там, где реально - это не принесёт подменившему никакой пользы, ссзб и пользы от знания ещё чьего-нибудь id не будет.
пользы от знания ещё чьего-нибудь id не будет.есть еще большое страшное зло - ошибки пользователей, которые плохо запомнили свой id (о чем я выше и писал)
Если через некоторое время формат базы изменится (пример: вас купила другая фирма и интегрировала со своей системой. или еще чо-нить то внезапно образуется гемор с тем, чтобы у клиентов остались те же id. Такое может оказаться сделать невозможным (при том же слиянии - если у той фирмы были те же значения придется огрести реально много проблем, чтобы заставить всех клиентов поменять этот id. У нас машины до сих пор с советскими номерами попадаются, а тут и вовсе жесть будет.
единственно нужно не переусердствовать в добавлении значимых цифр в номер
он может стать длинным и неудобно будет его запонимать, диктовать, вбивать и т.д.
он может стать длинным и неудобно будет его запонимать, диктовать, вбивать и т.д.
написал красиво
а пути решения то какие?
а пути решения то какие?
Может сначала узнать что за клиенты там будут и объемы данных в этой табличке? А потом ясно станет, стоит ли закладываться на возможные подобные изменения.
а пути решения то какие?то, что предлагает и активно использует, например, наша налоговая. Делаешь публичный id с контролем целостности (пример, как это можно сделать и табличку соответствия публичный id - внутренний id. При изменении системы достаточно просто можно будет сохранить внешние id, поменяв внутренние.
> вас купила другая фирма
> внезапно образуется гемор
дык это вроде уже не твои проблемы
> внезапно образуется гемор
дык это вроде уже не твои проблемы
Может сначала узнать что за клиенты там будут и объемы данных в этой табличке?не, ну ясно, что довольно часто можно сделать хоть как-то, а на потом забить. Это когда оплачивается только разработка, а не поддержка и развитие
дык это вроде уже не твои проблемыбывает очень по-разному
например, когда Google покупает какой-нибудь сервис, тот вынужден интегрироваться в общую инфраструктуру. А поскольку разработчики остаются те же, это их проблемы получаются.
конкретно чтобы пространства имён не пересекались - одно из стандартных решений - просто добавить доменное имя сайта, где клиент регистрируется, к id
> это их проблемы получаются
дык это разве проблемы
главное, чтоб платили за это
а раз купили, придётся платить
дык это разве проблемы
главное, чтоб платили за это
а раз купили, придётся платить
С тем же успехом можно позвонить и представиться соседом.
Хотя, конечно, бывают ситуации типа id сессии, когда важна рандомность.
Хотя, конечно, бывают ситуации типа id сессии, когда важна рандомность.
то, что предлагает и активно использует, например, наша налоговая. Делаешь публичный id с контролем целостности (пример, как это можно сделать и табличку соответствия публичный id - внутренний id. При изменении системы достаточно просто можно будет сохранить внешние id, поменяв внутренние.не согласен с тобой
не вижу причин разделять внутренний и внешний
добавляем контроль целостности к первичному ключу и все дела
не вижу смысла менять внутренние номера
даже если покупает другая фирма, без всякой смены номеров можно легко обойтись
ошибки пользователей, которые плохо запомнили свой idОбычно, когда пользователи звонят в службу техподдержки и называют свой числовой id, то, неважно, каким образом этот id генерился, у пользователя спрашивают ещё и (как подтверждение) какую-нибудь словесную характеристику - типа e-mail-а, кодового слова или фамилии.
даже если покупает другая фирма, без всякой смены номеров можно легко обойтисьну вот пусть у нас была аптека "Красный богатырь" и у нее были клиенты 1, 2, 3 и была аптека "Колеса-колеса", у которой были клиенты 1, 2, 3, 4. "Колеса-колеса" сумели скопить деньжат и купили "Красного богатыря". Вопрос - чо делать с клиентами "Красного богатыря"? Им вечно надо будет говорить "Клиент 1 из бывшего Красного Богатыря" или менять свой номер?
Обычно, когда пользователи звонят в службу техподдержки и называют свой числовой id, то, неважно, каким образом этот id генерился, у пользователя спрашивают ещё и (как подтверждение) какую-нибудь словесную характеристику - типа e-mail-а, кодового слова или фамилии.это хак, которым служба поддержки исправляет косяки разработчиков
Во-первых, я уже свечу. Во-вторых, я пока не вижу веских причин перестать это делать и именно о них и спрашиваю.
С физ. лицами и юр. лицами вообще беда, хоть отдельный топик заводи. Есть и те и другие. Пока расточено под физ. лиц. (в таблице клиенты есть поле ФИО, таблица клиенты связана, грубо говоря, с таблицей заказы). Про юридических лиц — компании — может быть известно начиная от одного анонимного email`а (company.com) и заканчивая координатами руководителя, секретаря, нескольких контактных лиц (с которыми и следует основную работу вести). Я решил, что юр. лица как таковые не являются клиентами, клиенты — это сотрудники компании. У клиента есть поле "компания". Для физ лиц оно пустое. Для представителей компаний — ссылка на контору. Буду признателен за комментарии к этому подходу. Что до идентификаторов, то и у тех и у других (и на самом деле еще у третьих) они выглядят одинаково.
С физ. лицами и юр. лицами вообще беда, хоть отдельный топик заводи. Есть и те и другие. Пока расточено под физ. лиц. (в таблице клиенты есть поле ФИО, таблица клиенты связана, грубо говоря, с таблицей заказы). Про юридических лиц — компании — может быть известно начиная от одного анонимного email`а (company.com) и заканчивая координатами руководителя, секретаря, нескольких контактных лиц (с которыми и следует основную работу вести). Я решил, что юр. лица как таковые не являются клиентами, клиенты — это сотрудники компании. У клиента есть поле "компания". Для физ лиц оно пустое. Для представителей компаний — ссылка на контору. Буду признателен за комментарии к этому подходу. Что до идентификаторов, то и у тех и у других (и на самом деле еще у третьих) они выглядят одинаково.
ну вот пусть у нас была аптека "Красный богатырь" и у нее были клиенты 1, 2, 3 и была аптека "Колеса-колеса", у которой были клиенты 1, 2, 3, 4. "Колеса-колеса" сумели скопить деньжат и купили "Красного богатыря". Вопрос - чо делать с клиентами "Красного богатыря"? Им вечно надо будет говорить "Клиент 1 из бывшего Красного Богатыря" или менять свой номер?вопрос в другом
как в твоей схеме это решится?
я не утверждаю что проблемы возникающие при дублировании номеров при слиянии двух баз легко решаются
я утверждаю что эти проблемы одинаково решаются в обоих случаях, тоесть когда 2 ключа и когда один ключ
у Карсного богатыря клиенты: 1 (id=100 2 (id=101 3(id=102)
у Колеса-колеса клиенты: 1(id=200 2(id=201 3(id=202)
дальше цитирую тебя:
Вопрос - чо делать с клиентами "Красного богатыря"? Им вечно надо будет говорить "Клиент 1 из бывшего Красного Богатыря" или менять свой номер?
> у пользователя спрашивают ещё и (как подтверждение) какую-нибудь словесную характеристику - типа e-mail-а, кодового слова или фамилии.
50/50,
в половине случае - эту информацию сообщает сама техподдержка (т.к. у них часто нет ни времени, ни желания ждать когда позвонивший вспомнить кто он такой - это актуально если под одним id-ом скрывается несколько человек(семья, компания:
- 458
- Вы Кузнецов?
- да
именно на этом социнжиниринг и строится.
50/50,
в половине случае - эту информацию сообщает сама техподдержка (т.к. у них часто нет ни времени, ни желания ждать когда позвонивший вспомнить кто он такой - это актуально если под одним id-ом скрывается несколько человек(семья, компания:
- 458
- Вы Кузнецов?
- да
именно на этом социнжиниринг и строится.
на уровне базы решаются одинаково, на уровне клиентов решать не надо совсем либо очень мало (т.к. при таком кодировании вероятность совпадения номеров заметно ниже просто автоинкремента). Т.е. мое предложение позволяет сэкономить на геморе с людьми, а не с базой. Люди как помнили свой старый номер, так и будут помнить. Он будет работать вечно, людям хорошо.
Позвони в любой банк и попробуй про номеру карты ФИО узнать. Все от ситуации зависит.
- 458
- Вы Кузнецов?
- да
и опять я не понял что ты сказал
может ты не понимаешь меня?
я говорю: не нужно делать два поля для id клиента
нужно делать одно поле, при этом не инкремент, а с контрольным числом
ты говоришь, что нужно делать два поля: одно инкремент, второе с контрольным
я с тобой категорично не согласен
мой аргумент: то твое первое поле, которое инкремент, нафик никому не нужно и нафик никому не нужно будет
где твой аргумент я не вижу
может ты не понимаешь меня?
я говорю: не нужно делать два поля для id клиента
нужно делать одно поле, при этом не инкремент, а с контрольным числом
ты говоришь, что нужно делать два поля: одно инкремент, второе с контрольным
я с тобой категорично не согласен
мой аргумент: то твое первое поле, которое инкремент, нафик никому не нужно и нафик никому не нужно будет
где твой аргумент я не вижу
> Позвони в любой банк и попробуй про номеру карты ФИО узнать. Все от ситуации зависит.
если известна инфа по структуре банка, то уже более менее реально.
привет Маш. Это Вася из соседнего отдела. У меня тут компьютер навернулся, а на проводе висит недовольный клиент с id 458, посмотри, пожалуйста, кто это такой.
если известна инфа по структуре банка, то уже более менее реально.
привет Маш. Это Вася из соседнего отдела. У меня тут компьютер навернулся, а на проводе висит недовольный клиент с id 458, посмотри, пожалуйста, кто это такой.
теперь понял тебя. =)
Да, можно и так. Сходу придумать ситуации, когда это плохо, не могу. Мб их и в самом деле немного.
Да, можно и так. Сходу придумать ситуации, когда это плохо, не могу. Мб их и в самом деле немного.
А по определителю номера она не видит нихрена...
Лан разговор ниочем.
Лан разговор ниочем.
привет Маш. Это Вася из соседнего отдела. У меня тут компьютер навернулся, а на проводе висит недовольный клиент с id 458, посмотри, пожалуйста, кто это такой.жжошь!
Митника начитался?
Да, можно и так.я кстати это говорю имея ввиду реальный пример
в нашем идиотском райфайзене два поля id
в результате геморроя выше крыши
а щас еще с базой импекса будем связываться и ваще пипец что будет твориться
кстати, номера подряд идут
правда клиентский номер клиенты не знают, он нужен для общения между сотрудниками компании
> А по определителю номера она не видит нихрена...
видит мобильник, и что?
значит фразу надо построить так, чтобы из фразы неявно было понятно, почему Вася звонит именно с мобильника, а не с внутреннего телефона.
видит мобильник, и что?
значит фразу надо построить так, чтобы из фразы неявно было понятно, почему Вася звонит именно с мобильника, а не с внутреннего телефона.
> Митника начитался?
и его в том числе
а так, все такие разводки идут по одной и той же схеме, взять те же разводки по телефону про попадание в аварию: узнаем личную инфу о человеке, и делаем вид, что мы с ним знакомы.
и его в том числе
а так, все такие разводки идут по одной и той же схеме, взять те же разводки по телефону про попадание в аварию: узнаем личную инфу о человеке, и делаем вид, что мы с ним знакомы.
ггг
а с чем геморрой, кстати? я же советовал, т.к. похоже не вижу проблем, которые у вас возникли
а с чем геморрой, кстати? я же советовал, т.к. похоже не вижу проблем, которые у вас возникли
а с чем геморрой, кстати?в базе некторые таблицы ссылаются на одно поле
некторые на другой
потом у нас много баз, в одних одно хранится в других другое
первичные ключи там разные, в базе соответствие лежит этих двух ключей, тоесть тебе чтобы какието данные получить, надо слазить в эту таблицу соответствий, выудить нужный айди а потом лезть в нужную таблицу
понятно что кривые руки и разработчиков бд, но ведь было бы гораздо проще жить если бы айди был один во всех базах
По нескольким таблицам инфу о "Партнере" нужно разложить. Хотя это еще полбеды.
Что делать когда Юр.лицо меняет название/форму собственности/еще что-нибудь? Заводить нового партнера? А итоги хочется считать именно по партнеру, и не важно что с января по май он назывался "Иван Иваныч, ООО", а с мая "Федор Юрьевич, ЗАО".
Что делать когда Юр.лицо меняет название/форму собственности/еще что-нибудь? Заводить нового партнера? А итоги хочется считать именно по партнеру, и не важно что с января по май он назывался "Иван Иваныч, ООО", а с мая "Федор Юрьевич, ЗАО".
А твои варианты?
Генерить id-шники каким-то другим образом, и потом огрести те же неприятности на свою задницу? Только тогда уже, скорее всего, не выйдет сказать "пользователи красного богатыря, вы теперь пользователи колёс-колёс, прибавьте миллион к своему id".
Генерить id-шники каким-то другим образом, и потом огрести те же неприятности на свою задницу? Только тогда уже, скорее всего, не выйдет сказать "пользователи красного богатыря, вы теперь пользователи колёс-колёс, прибавьте миллион к своему id".
А добавлять сущности в базу вы не можете? Для критичных таблиц можно и два поля "Id" заиметь. Ну как вариант...
Для критичных таблиц можно и два поля "Id" заиметь.так и есть
социнжинирингЧего-чего?
- 458Если спрашивают "Вы Кузнецов Иван Иванович" (т.е. возможность совпадения минимальна то, в общем-то, если человек сказал "да", хотя это не его id - ссзб.
- Вы Кузнецов?
- да
не, ну понятно, что это жесть и не то, что предлагалось мной
мое предложение было, что в базе есть ровно одна таблица, где хранятся внешние id-и, а больше никто на них не ссылается и не хранит.
мое предложение было, что в базе есть ровно одна таблица, где хранятся внешние id-и, а больше никто на них не ссылается и не хранит.
привет Маш. Это Вася из соседнего отделаАга, а звонок по локальному телефону?
Тогда уж и самому можно в компьютере посмотреть.
Генерить id-шники каким-то другим образом, и потом огрести те же неприятности на свою задницу? Только тогда уже, скорее всего, не выйдет сказать "пользователи красного богатыря, вы теперь пользователи колёс-колёс, прибавьте миллион к своему id".не вижу, в чем проблемы моего варианта. Покажи на примере
Ага, а звонок по локальному телефону?ты обсуждение читаешь или только пишешь? там уже было про то, что звонить по мобильному и объяснять почему именно с мобильного (пример: на локальном телефоне этот клиент и висит)
Тогда уж и самому можно в компьютере посмотреть.
А итоги хочется считать именно по партнеру, и не важно что с января по май он назывался "Иван Иваныч, ООО", а с мая "Федор Юрьевич, ЗАО"."Иван Иваныч, ООО" и "Федор Юрьевич, ЗАО" - это совершенно разные организации и пользователи.
Если ты их объединяешь в одного партнёра - значит, тебе надо ещё таблицу "партнёры" (и "пользователи партнёра" где будет написано "Партнёр1 - это Иван Иваныч и Федор Кузьмич".
Я тут, наверное, немного пропустил - твой вариант - это какой?
Мне в голову пока что приходит только генерить идшники рандомно.
Мне в голову пока что приходит только генерить идшники рандомно.
Мне в голову пока что приходит только генерить идшники рандомно.вроде про это и говорили
генерить рандомно, но потом добавлять контрольные цифры
>> "Иван Иваныч, ООО" и "Федор Юрьевич, ЗАО" - это совершенно разные организации и пользователи.
Ты, точно ничего не читал. Юридически это два разных юр.лица, физически - нет.
>> Если ты их объединяешь в одного партнёра - значит, тебе надо ещё таблицу "партнёры"...
Таблиц можно сколько угодно насоздавать. Только потом к ним запросы писать, и нужно что б это все еще и шустро работало...
Ты, точно ничего не читал. Юридически это два разных юр.лица, физически - нет.
>> Если ты их объединяешь в одного партнёра - значит, тебе надо ещё таблицу "партнёры"...
Таблиц можно сколько угодно насоздавать. Только потом к ним запросы писать, и нужно что б это все еще и шустро работало...
Юридически это два разных юр.лицаЭто я и имел в виду.
нужно что б это все еще и шустро работалоНу ты тогда определись, надо, чтобы всё было крайне оптимизировано, или чтобы всё было понятно.
Редактировать этого самого партнера. Вместо "Иван Иваныч, ООО" сделать "Федор Юрьевич, ЗАО". В чем проблема?
ыыыыыыы
переведи, плз
В чем проблема?так не делают
Млин, я весь тред затеял из-за одного вопроса: почему люди так не делают. Из-за моды что-ли?
Что плохого в переименовании сущности в базе вместе с ее изменением в реале?
1. Корежится прошлое. То есть с точки зрения базы контра всегда была ОАО и старые заказы были тоже с ОАО. Меня это не беспокоит.
2. Проблема слияния в базе при поглащении в реале? У меня не те масштабы, чтоб это произошло, я думаю.
Еще?
Что плохого в переименовании сущности в базе вместе с ее изменением в реале?
1. Корежится прошлое. То есть с точки зрения базы контра всегда была ОАО и старые заказы были тоже с ОАО. Меня это не беспокоит.
2. Проблема слияния в базе при поглащении в реале? У меня не те масштабы, чтоб это произошло, я думаю.
Еще?
второе бред
так не делают из-за первого
если тебя это не беспокоит - делай
в будущем когда будет икаться, знай, тебя матом вспоминает тот кто пришел на твою работу после тебя
так не делают из-за первого
если тебя это не беспокоит - делай
в будущем когда будет икаться, знай, тебя матом вспоминает тот кто пришел на твою работу после тебя
Можно псевдорандомно. Например, умножение 32битного числа на хорошее число (взаимно простое с модулем и ещё что-то, это неважно, ведь можно тупо проверить хорошесть) по модулю даёт все эффекты хэша, но при этом полностью обратимо. Например,
public static uint HashUint(uint u)
{
return (u * 123456789) ^ 0xCAFEBABE;
}
public static uint UnhashUint(uint u)
{
return (u ^ 0xCAFEBABE) * 102505021;
}
Если никому не говорить Кодовое Число, то всё будет совершенно замечательно.
public static uint HashUint(uint u)
{
return (u * 123456789) ^ 0xCAFEBABE;
}
public static uint UnhashUint(uint u)
{
return (u ^ 0xCAFEBABE) * 102505021;
}
Если никому не говорить Кодовое Число, то всё будет совершенно замечательно.
Млин, я весь тред затеял из-за одного вопроса: почему люди так не делают. Из-за моды что-ли?Делают, называется медленно меняющееся измерение типа 1. (В англоязычной литературе Slowly Changing Dimension type 1).
Основные недостатки:
1. Уже названная потеря истории.
2. Проблемы слияния записей, т.е. когда до того разные сущности вдруг становятся одной. Например при объединении двух фирм, каждая из которых была твоим клиентом или (что гораздо реальней) когда твой клиент уже имея номер не сообщил его, получил новый и пользуется теперь и тем и другим. И это будет только его проблема пока он не запутается окончательно и не начнет крыть матом операционистку из-за того что он назвал один номер, а заказ был сделан на другой и ему сказали что он ничего не получит.
P.s. А мода сейчас не терять информацию вообще (объёмы-то смешные вдруг пригодится.
Вопрос - чо делать с клиентами "Красного богатыря"? Им вечно надо будет говорить "Клиент 1 из бывшего Красного Богатыря" или менять свой номер?Пользуй GUID в качестве ключа и не будет таких проблем.
социнжинирингЕсли "чего-чего", то за каким делом ты лезешь во взрослый разговор?
Чего-чего?
Ага, а звонок по локальному телефону?Это ну настолько очевидно, что даже немного неловко объяснять.
Тогда уж и самому можно в компьютере посмотреть.
Например, компания большая, международная, телефоны у всех указаны городские, а не внутренние, чтобы иностранные коллеги дозванивались.
Ну и миллион других вариантов.
А как называется паттерн, который нынче в моде? Ибо проблема слияния уже встала и как раз по причине того, что куча клиентов по несколько раз оказалась введенной.
Например, компания большая, международная, телефоны у всех указаны городские, а не внутренние, чтобы иностранные коллеги дозванивалисьА что, аналога vpn в мире телефонов не существует?
Вот если бы ты сначала почитал, что такое социальная инженерия, а потом пришел сюда светить своей образованностью, у тебя бы вопроса не возникло.
Но я все равно отвечу, потому что мне нравится самоутверждаться за счет дураков:
что бы не было придумано, часть этого не реализуют на практике, а часть можно обойти за счет людских ошибок.
Но я все равно отвечу, потому что мне нравится самоутверждаться за счет дураков:
что бы не было придумано, часть этого не реализуют на практике, а часть можно обойти за счет людских ошибок.
часть этого не реализуют на практикеССЗБ.
Тогда уже не имеет смысла говорить "а давайте применим такое кривое решение, которое нас спасёт в случае, если мы не применим нормальное универсальное решение",
а часть можно обойти за счет людских ошибок.Сотрудникам строго запрещено раскрывать какую-то внутреннюю информацию при звонке не на внутренний телефон/сообщении на внешнюю аську, а не на другой менеджер, подключеный к внутренней сети.
Сотрудникам строго запрещено раскрывать какую-то внутреннюю информацию при звонке не на внутренний телефон/сообщении на внешнюю аську, а не на другой менеджер, подключеный к внутренней сети.кто отменил атаки на корпоративный АТС?
Сотрудникам строго запрещеноДа, разумеется. Строго запрещено.
Еще раз - иди почитай, потом приходи выебываться.
Оставить комментарий
Realist
Добрый день, всезнающий олл!Я тут вояю базу клиентов. Там у каждого клиента есть уникальный номер, который снимает вопрос о том, как различать тёск ну и вообще на мой взгляд вещь полезная. Мы его клиентам сообщаем, потому что если клиент захочет обратиться с каким-либо вопросом, найти его в базе по этому номеру, очевидно, просто. В качестве этого номера я, не долго думая, стал использовать первичный ключ (id который автоматически инкрементально генерируется при добавлении записи. Что-то мне подсказывает, что обычно делают не так. Почему?
Пока я знаю (понял) следующие соображения:
1. По своему номеру клиент может оценить общее число клиентов. — Мне не жалко.
2. Число знаков номера не унифицировано. — В icq тоже не унифицировано, никто не обламывается.
3. Нельзя поменять номер клиента. — Его, вроде бы, и не нужно менять. Ибо он ничему в реальном мире не соответствует.