Сэм
агностик
Тема: #85485
Сообщение: #3259365
10.09.09 04:07
|
***...останется только самая серьезная - проблема уязвимости.***
Ессно, такая база будет работать исключительно в спец. сетях. Никто не даст к ней доступ из инета.
А что касается взлома кем то внутри самой сети - риск есть. Примерно такой же, как кто то внутри организации, пользуясь связями с нужными людьми, фальсифицирует служебные документы.
***ФИО и место рождения не гарантирует уникальность.
...с датой рождения - гарантируют.***
Тоже не гарантируют. Чисто теоретически, есть вероятность что в одном городе, в один день родятся два Иванова Ивана Ивановича ))) (Ну, или в разных городах, но одинаково называющихся)
***Кроме того, это слишком неудобно для автоматизированной обработки.
В чем же неудобство - в каскадном поиске? Ну и что, шибко много времени, для машины, занимает прыганье по ступенькам? А про возможность поиска по дате и месте рождения == повышенная надежность, что помалкиваете? Или недодумываете?***
В любом случае, самый быстрый поиск по целочисленному ID. Это не значит, других вариантов нет, но они более ресурсоемкие.
Далее: Место рождения может быть записано разными способами. Например, сначала населенный пункт был поселок, а затем получил статус города. Придется тянуть за собой все наследия прошлого.
Или, например, человек родился за границей, в городе, название которого не имеет очевидного, однозначного написания? Одни операторы будут вводить один вариант, другие - другой. Зачем нужен это геммор, если достаточно все данные просто привязать к ID?
***И с чего Вы взяли, что id привязан исключительно к ФИО? - коллизии будут, однако. Поэтому, чтоб через классические ФИО/др/мр добраться до id, нужно пройти ФИО - др - мр. И зачем тогда этот id, извините, нужен? Чтоб был? Зачем его делать глобальным? Зачем под него забивать место в записи? Несуразица сплошная.***
Как раз наоборот. Несуразица - это юзать ФИО в качестве ключа (внутреннего), вместо ID.
1. Более медленный поиск привязанных записей к master-таблице. (Вот тут - это уже действительно критично)
2. В привязанных таблицах будут дублироваться ФИО и пр. Зачем такие затраты??? Я уж не говорю об остальных "прелестях" такого подхода.
В данном случае, ID - это primary key. Все остальные записи, связаны через этот ID-шник. Ну блин... элементарная реализация отношения один-ко-многим.
И прелесть личного идентификатора в том, что в качестве входной информации оператор вводит непосредственно ID.
А вообще, описанный вами подход имеет место быть. Иногда. Мне приходилось встречать БД, где в качестве ключа для связей использовалась введнная пользователем информация, в свободной форме. "Удовольствие" работы с такими базами - еще то.
Я думаю, что о том какие дополнительные сложности вызывает такой подход - вы и сами прекрасно знаете.
***Только в случае краша не компу придется эти дела разгребать.***
Что то мне подсказывает, что БД не будет храниться в единственном экземпляре на компе президента )))
Люди уже давно научились сводить последсвия крэша БД к минимуму.
***Простой как грабли, который остается постоянным на все время существования БД.
Как детские грабли, на которые наступят после первой серьезной вспышки на солнце или местной катастрофы на ас, или землетрясения, или военного конфликта и т.д.***
Не драмматизируйте. Даже у нас в оффисе, что бы полностью полетела БД системы контроля версий, нужно что бы одновременно что-то страшное приключилось одновременно как минимум в двух странах. )))
***1. Как думаете, оператору, чтоб не ошибиться, что проще набрать, ФИО и др, или последовательность из 18 циферок?***
Вот именно, что ФИО, др, мр. Я описал проблему с этими данными. Проще ввести 18 цифирок.
***Глобальной базе достаточно дать запрос локальной бд - вот и вся Ваша надуманная "масса проблем".***
И что, по вашему это решит проблему не-уникальности ключа? Очевидно, что чисто теоретически - такая проблема есть. Значит есть не нулевая вероятность, что она может и на практике когда нить всплыть.
***Значит, не надо ее вообще использовать. И не надо было тратить деньги налогоплательщиков на заведомо провальный проект.***
С чего это он заведомо провальный??? Везде работает, а у вас почему то провальный.
***Да ничем она жизнь не облегчит. Совершенно ничем. Только усложнит. Более того, у кого будет доступ изменять инфу в глобальной БД, станет попросту неограниченным в политической и экономической власти на Земле.***
Облегчит в первую очередь тем, кто с этим работает. Да и пластиковую карточку и ID таскать проще, чем паспорт.
Что касается злоупотреблений, то они есть в любой системе. Как бумажной, так и электронной.
***И кто ж это посчитал, кто в "большинстве", а кто в "меньшинстве"?***
Я исхожу из того, что в реальной жизни, мне не доводилось встречать противников ИНН, мотивирующих свое неприятие тем, что это якобы наложит печать на их личность. О таких людях узнаю либо на формуах, либо по телеку.
Что касается противников с иной мотивацией, да конечно. Их довольно много.
Я и сам, как человек, отношусь к тотальной идентификации подозрительно и заранее скептически.
Подозрительно - потому что это дает более легкую возможность вести тотальный контроль. Исходя из того, что никакому правительству, где бы оно ни было, я нифига не доверяю, меня эта возможность напрягает.
А скептически, потому что у нас в стране, как обычно все сделают через, простите, задницу. И сведут на нет, все удобства, которые могли бы быть. Как я уже неоднократно наблюдал, никакие высокие технологии не способны извести нашу бумажную волокиту.
Но чисто технически - эта идея мне по душе.
|
