Наткнулся вот на такую ссылку, активно обсуждаемую.
http://subscribe.newsland.ru/link.php?M=12827183&N=6968&L=256266&F=H
Но уж очень там всё злобно как-то. Оно и понятно, люди, ведь в подобных местах общаются в основном безверующие.
Меня лично приятно удивила такая инициатива Патриарха. Не ожидал я от него этого шага. А вы как к данному поступку относитесь?
И про номера, и про апробируемые активно уже сейчас способы управления человеком с использованием микрочипов, внедренных в организм. Обсуждалось уже в теме 85585.
Хотели бы Вы перевоплотиться в киборга?
***Не нахожу ничего сложного в алгоритме обработки данных, идентифицируемых через ID.
Точно не находите? Ну так смотрите:
1. [id][фио][проч.]
2. [фио][проч.]
Вот и скажите, будет ли алгоритм для случая 1. проще чем для случая 2., если случай 2. для 1. так же должен быть обязательно реализован (да-да, на случай краша, забывчивых клиентов и т.д.)
***
Ну смотрите. Например в базе хранятся данные о человеке, местах его работы, судимостях, болезнях, лекарствах, которые он покупал и истории его болезней. То есть чем и когда он "официально" болел. По сути - зафиксированы его походы к врачам.
Как будут выглядеть SQL запросы для выборки этих данных, удаления и смены фамилии/места жительства для:
а) Случая с уникальным целочисленным ID
b) Случая с составным ключом, коим служат ФИО др мр.
?
Если в первом случае, для того что бы выбрать данные о больничных достаточно запроса вроде:
select * from RootTable, SickList where RootTable.ID = SickList.PersonID
то для второго нужно будет уже совсем не так:
select * from RootTable, SickList WHERE (RootTable.FName = SickList.FName) AND (RootTable.MName = SickList.MName) AND (RootTable.LName = SickList.LName) AND (RootTable.BirthDate = SickList.BirthData) AND (RootTable.BirthPlace = SickList.BirthPlace)
И это простейший случай, где мы заюзали только одну связанную таблицу. А если что то более сложное?
А удаление записи? А смена ФИО? А переименование города, в котором человек родился?
Я уж не говорю о чудовищном перерасходе места за счет дублирования такого кол-ва информации.
***Себе противоречите. Ибо глобальный id будет именно пользовательскими данными - новым именем пользователя.***
По сути - ФИО это пользовательские данные. Пользователь с ней что хочет - то и делает. Захотел - сменил. С ID он так не поступает. ID "придумывает" машина, она отвечает за его уникальность и он предназначен ТОЛЬКО для этого. Меняться он не может.
Ну и зачем эти "костыли"?
Это уже сейчас не костыли.
Эти три цифры будут говорить о том, где получен ИД, а не где живет человек.
...значит, зарезервировав под исчезнувшую страну несколько позиций в id, мы их навеки потеряем с исчезновением страны. Либо придется менять алгоритм присвоения глобального id.
Не нахожу ничего сложного в алгоритме обработки данных, идентифицируемых через ID.
Точно не находите? Ну так смотрите:
1. [id][фио][проч.]
2. [фио][проч.]
Вот и скажите, будет ли алгоритм для случая 1. проще чем для случая 2., если случай 2. для 1. так же должен быть обязательно реализован (да-да, на случай краша, забывчивых клиентов и т.д.)
Меня просто ваша фамилия с толку сбила :)))
Хе-хе, просто увлекаетесь вкуснохрустящимы мышками по утрам. ;)))
Лично для меня, очевиден принцип, что пользовательские данные ни в коем случае не должны являться ключом.
Себе противоречите. Ибо глобальный id будет именно пользовательскими данными - новым именем пользователя.
Ну что же, удачи вам, в нашем нелегком деле программостроения :)))
Спасибо, хотя серьезно этим я давно не занимаюсь. :)
***Поменять. В случае с изменением ФИО - хранить историю изменения оного.***
Ну и зачем эти "костыли"?
***Сорри, но мелкая БД - это мелкая БД. В глобальных таки другие проблемы. Грубо говоря, если соседям "нашего двора" достаточно знать ФИО, то в рамках населенного пункта этого уже не достаточно.***
Другие. Но решать эти проблемы теми методами, которые плохо себя зарекомендовали даже на маленьких БД, было бы как то странно.
***И как же оные методы справятся с задачей в случае тотальной миграции? Не забывайте, что под глобальный id уже забито три шестизначных позиции. Не меньше и не больше.***
Эти три цифры будут говорить о том, где получен ИД, а не где живет человек.
***А вот в случае отсутствия привязки к глобальному id этого вообще не требуется.***
Конечно. Вместо того что бы завести одну таблицу (которой еще не факт, что придется когда нить воспользоваться), нужно будет завести много таблиц, которыми все время нужно будет пользоваться.
***Имеет. Ибо исчезнут машины - человек остается. Исчезнет человек - тогда вообще речь вести не о чем. Поэтому фиодрмр, в случае тотального краша, имеет несомненное преимущество.***
Если "исчезнут машины", то будет уже без разницы, как именно там хранились данные - в "естественном для человека виде" или "неестественном". Не так ли?
Тем более, я уже говорил, что в случае если это произойдет, автоматически происходит откат к прежней схеме. Бумажные документы, никто не отменял. Разница лишь в том, что при действующей электронной системе, бумаги заполняются и отправляются в архив.
***А кто вам мешает восстановить всю инфу вместе с ID?
Ну а смысл тогда в существовании этой самой, столь уязвимой и кибер-зависимой, глобальной id? Опять восстанавливать, чтоб опять потерять? - детские грабли.***
Нет, постойте. Вы утверждаете, что систему без ID можно восстановить. Вопрос был: "А что мешает восстановить систему вместе с ID?"
***Я так думаю, что если у программера возникает какая то "непрозрачность" доступа к данным через ID, то его от БД нужно держать подальше. Вы не согласны?
Я не про алгоритм доступа, а про алгоритм обработки.***
Не нахожу ничего сложного в алгоритме обработки данных, идентифицируемых через ID.
***Что-то не верится, что тетрада из шести позиций никогда не изменится. Или великие архитекторы глобального id пророчат, что цивилизация, под их чутким руководством, на вечное существование не претендует? :) Или подзабытая проблема 2000 года ничему не научила?***
На ближайшее время хватит :)
"Проблема 2000", как вы знаете, была слегка раздута. И обошли ее без каких либо фатальных последствий.
***Естественно второе. Вообще, живое, по Вашему, ближе к чему - к первому или второму случаю?***
Хорошая идея! Надо будет маркетингу предложить, что бы наши девайсы иногда "ошибались" или "забывали" какие нить данные. Или "паниковали" в экстремальных условиях :))) Это более близко к живому, к человеку. :)))
***А что, уникальный id, как "вещь в себе", нужОн? Или он таки "для блага человечества" предназначен? - столь изменчивого и непостоянного.***
Ничего не понял... Вы сплели воедино чисто техническую часть и какие то "глобальные проблемы человечества". Чисто технически - он очень даже нужОн :) А о философском аспекте, я буду думать, когда переключу моск в режим "юзер" :)))))
Тем более, я уже высказывал свое обывательское отношение к этому вопросу. Но оно имеет весьма слабое отношение к моему взгляду, в качестве программера.
***Вы настолько увлечены идеей id, что уже второй раз называете "Ильей" "Андрея". Значит, "мышку не съедите"? - ну-ну. ;)***
Блин! Сорри, Андрей! :)))
Меня просто ваша фамилия с толку сбила :)))
***правильно ли я понимаю, что если бы у вас возникла бы задача писать базу данных при наличии полной свободы действий то вы бы в качестве уникального идентификатора выбрали бы именно ФИО м.р.д.р. ?
Именно. Во всяком случае, это было бы хребтом.***
Ясно.
Лично для меня, очевиден принцип, что пользовательские данные ни в коем случае не должны являться ключом. Так как практика неоднократно показывала нецелесообразность (а иногда и пагубность) такого подхода. Так же, как и то, что составной ключ (особенно из текстовых полей) лучше использовать лишь в крайних случаях, когда по другому - никак. Да и "умные книги" всегда говорят о том же. ID - отдельно, пользовательские данные - отдельно.
Видимо, ваша практика подсказывает вам другое.
Ну что же, удачи вам, в нашем нелегком деле программостроения :)))
Ну и что делать если название населенного пункта поменяется?
Поменять. В случае с изменением ФИО - хранить историю изменения оного.
Если даже на мелких БД никто не хочет геммороиться с такими "веселыми" ключами, то что уж говорить о больших масштабах?
Сорри, но мелкая БД - это мелкая БД. В глобальных таки другие проблемы. Грубо говоря, если соседям "нашего двора" достаточно знать ФИО, то в рамках населенного пункта этого уже не достаточно.
Если даже на мелких БД никто не хочет геммороиться с такими "веселыми" ключами, то что уж говорить о больших масштабах?
И как же оные методы справятся с задачей в случае тотальной миграции? Не забывайте, что под глобальный id уже забито три шестизначных позиции. Не меньше и не больше.
Первая же идея, пришедшая в голову - хранить "запасную таблицу", с соответствиями ID и пасспортных данных.
А вот в случае отсутствия привязки к глобальному id этого вообще не требуется.
Не имеет к данному вопросу ни малейшего отношения. Мы обсуждаем техническую часть.
Имеет. Ибо исчезнут машины - человек остается. Исчезнет человек - тогда вообще речь вести не о чем. Поэтому фиодрмр, в случае тотального краша, имеет несомненное преимущество.
А кто вам мешает восстановить всю инфу вместе с ID?
Ну а смысл тогда в существовании этой самой, столь уязвимой и кибер-зависимой, глобальной id? Опять восстанавливать, чтоб опять потерять? - детские грабли.
Я так думаю, что если у программера возникает какая то "непрозрачность" доступа к данным через ID, то его от БД нужно держать подальше. Вы не согласны?
Я не про алгоритм доступа, а про алгоритм обработки.
Какая система более подвержена сбоям, та где есть целочисленный ключ, который НИКОГДА не меняется, или та, где ключем является набор текстовых полей, которые периодически подвергаются изменениям с необходимостью их дальнейшей синхронизации?
1. Никогда не говори "никогда" (это уже уязвимость, кстати ;)).
2. Что-то не верится, что тетрада из шести позиций никогда не изменится. Или великие архитекторы глобального id пророчат, что цивилизация, под их чутким руководством, на вечное существование не претендует? :) Или подзабытая проблема 2000 года ничему не научила?
3. Естественно второе. Вообще, живое, по Вашему, ближе к чему - к первому или второму случаю?
Вообще не понял... Винты хранящие паспортные данные более неприхотливы, чем винты хранящие ID???
1. Почти Маяковский: я достаю из широких штанин, флешку бесценного груза, считайте, зависните, я гражданин, Глобального Союза. :))
2. Я к тому, что бумажный паспорт надежней кибер-устройства. :)
Хорош "уникальный ID", который имеет свойство меняться...
А что, уникальный id, как "вещь в себе", нужОн? Или он таки "для блага человечества" предназначен? - столь изменчивого и непостоянного.
Илья, правильно ли я понимаю, что если бы у вас возникла бы задача писать базу данных при наличии полной свободы действий то вы бы в качестве уникального идентификатора выбрали бы именно ФИО м.р.д.р. ?
Именно. Во всяком случае, это было бы хребтом. p.s. Вы настолько увлечены идеей id, что уже второй раз называете "Ильей" "Андрея". Значит, "мышку не съедите"? - ну-ну. ;)
уникальный и неизменный целочисленный идентификатор менее удобен и надежен, нежели комбинация из нескольких текстовых полей.
Конечная целочисленная комбинация менее удобна (для человека, а машине все равно) и надежна, нежели чем комбинация из нескольких текстовых полей.
***...коим в полной мере является и с успехом используется ФИО-др-мр. И гемор с присваиванием глобального id ему не грозит.***
Ну и что делать если название населенного пункта поменяется? Я уже поднимал этот вопрос, кстати.
***Такой поиск и я с трудом представляю. ;)***
Ну вот видите... А говорите, нужен поиск по локальным БД
***А причем здесь "мой случай", если мы говорим о глобальном id?***
А там что, БД будет строиться по каким то совершенно новым принципам? Если даже на мелких БД никто не хочет геммороиться с такими "веселыми" ключами, то что уж говорить о больших масштабах?
***Вероятность коллизий? Так ведь и глобальный id несет в себе этот изъян - в момент присвоения уникального глобального id. Про синхронизацию я вообще молчу.***
Каким же это образом возникнут коллизии с глобальным ID? Он же генерируется в одном месте. Новая запись - новый ID.
Про синхронизацию - я тоже молчу. В наш век, когда люди летают в космос и всячески бороздят просторы большого театра, вы все еще видите проблему в элементарной задаче синхронизации доступа к генератору ID :)))))))) Это же задача уровня студента... Ну... правда если речь не идет о кластере... Но и там существуют давно отработанные методы.
Далее, рассмотрим приведенные вами преимущества:
1. Отсутствием жесткой привязки к глобальному id.
Такая связь восстанавливается на "раз-два". Первая же идея, пришедшая в голову - хранить "запасную таблицу", с соответствиями ID и пасспортных данных. И делов то... Вы видите проблему на пустом месте.
2. Отсутствием полной зависимости цивилизации от кибер-систем и контролирующих оные системы персон.
Нет никакой "полной зависимости". В случае гипотетического (маловероятного), тотального крэша, со всеми зеркалами и бэкапами, мы просто делаем шаг назад, к той системе, которая у нас есть. Я уже приводил пример с системами электронного документооборота.
3. Соответствием человеческому образу мышлению.
Не имеет к данному вопросу ни малейшего отношения. Мы обсуждаем техническую часть.
4. Повышенной устойчивостью к сбоям.
И вы действительно верите в то, что синхронизация по одному целочисленному полю, менее устойчива к сбоям, чем синхронизация по нескольким текстовым полям???
Какая система более подвержена сбоям, та где есть целочисленный ключ, который НИКОГДА не меняется, или та, где ключем является набор текстовых полей, которые периодически подвергаются изменениям с необходимостью их дальнейшей синхронизации?
5. Возможностью полного восстановления ключевой инфы даже в случае полного уничтожения бд.
А кто вам мешает восстановить всю инфу вместе с ID?
6. Неприхотливостью к источника хранения инфы.
Вообще не понял... Винты хранящие паспортные данные более неприхотливы, чем винты хранящие ID???
7. Прозрачным алгоритмом доступа к информации.
Я так думаю, что если у программера возникает какая то "непрозрачность" доступа к данным через ID, то его от БД нужно держать подальше. Вы не согласны?
Или вы про пользователей? А у пользователя вообще все прозрачно. Ему не нужно знать о всех этих заморочках. Все что от него требуется, это ввести "магические циферьки", которые напечатаны на пластиковой карте клиента.
***Поймите, что уникальный id уже есть, ***
Хорош "уникальный ID", который имеет свойство меняться...
Илья, правильно ли я понимаю, что если бы у вас возникла бы задача писать базу данных при наличии полной свободы действий то вы бы в качестве уникального идентификатора выбрали бы именно ФИО м.р.д.р. ?
Под "свободой действий", я в данном случае понимаю введение любых законов + абстрагирование от любых этических норм.
То есть, я просто сейчас хочу понять. То ли в данном случае, ваши убеждения "подгоняют под себя" ваше мышление специалиста, то ли действительно вы твердо убеждены, что уникальный и неизменный целочисленный идентификатор менее удобен и надежен, нежели комбинация из нескольких текстовых полей.
Какое самое удобное средство для установления однозначного соответствия между Ивановым Иваном Ивановичем в моей базе, и Ивановм в ГАИ-шной? Конечно же, уникальный идентификатор.
...коим в полной мере является и с успехом используется ФИО-др-мр. И гемор с присваиванием глобального id ему не грозит.
Лично я, такой поиск представляю с трудом :))) Такой поиск и я с трудом представляю. ;)
Скажите, и часто у вас в компании применяют такие вот "классические решения"?
А причем здесь "мой случай", если мы говорим о глобальном id?
Мы начинаем ходить по кругу.
Ага.
Я уже приводил вполне определенные аргументы "против" такой идентификации.
Вероятность коллизий? Так ведь и глобальный id несет в себе этот изъян - в момент присвоения уникального глобального id. Про синхронизацию я вообще молчу.
Утверждние, "так надежнее", пока что не является аргументом, потому что вы так и не пояснили, ЧЕМ ЖЕ именно надежнее
1. Отсутствием жесткой привязки к глобальному id.
2. Отсутствием полной зависимости цивилизации от кибер-систем и контролирующих оные системы персон.
3. Соответствием человеческому образу мышлению.
4. Повышенной устойчивостью к сбоям.
5. Возможностью полного восстановления ключевой инфы даже в случае полного уничтожения бд.
6. Неприхотливостью к источника хранения инфы.
7. Прозрачным алгоритмом доступа к информации.
Пока хватит.
использование ID - более удобно и обоснованно, чем остальные данные.
Поймите, что уникальный id уже есть, просто он выражен в формате фиодрмр. Зачем изобретать велосипед и тем паче, сводить его к тетраде из шести позиций?
Если вы придете устраиваться на работу, и HR, сверившись с документами, скажет вам - "Здравствуйте, миллионстотысячтристсемидесятый миллионтреставосемьдесяттысячсемьдесятседьмович!", то я съем свою мышь вместе с разъемом и PS2 адаптером :)))
Вы то может и не съедите. А вот за детей и внуков уже не зарекайтесь.
====Я в этом деле дилетант, и на мой дилетантский взгляд, тут возникает ряд вопросов......... Но воздействие должно быть скрытым, именно в этом вся сила. А так, любой поймет, что в данный момент, на него воздействуют.====
Возможности воздействия могут быть самыми разнообразными. Их исследуют "соответствующие службы. И вероятно добиваются успехов. Нам же об этом не сообщают. А если и сообщают то вероятно о самых примитивных возможностях воздействия или таким образом, что бы мы не понимали истинной сути явления и не могли его использовать или защититься. Вот и всё.
===прочем, я не спец по этому вопросу. Интересно, что скажут люди, имеющие профессиональное отношение к данному вопросу...===
Думаю, что ничего. В силу специфики.
===Так что я, скорее противник "чипизации", чем сторонник. Другое дело, что я пытаюсь отделить для себя реальные угрозы от страшилок и предрассудков.===
Это конечно интересно, но главное - бороться с этим. Хотя, я так понимаю всё равно это будет. :(
***Но нужен, что бы заносить эти бумаги в базу.
В случае краша что ли? Id же будет присваивать машина, а не человек. Человек буде вносить ФИО и проч. А машина "обзывать" своим машинным именем. Или я не прав?***
Не... Глобальный ID будет использоваться для установления однозначного соответствия между данными, хранящимися в разных базах. Вот, например, у меня есть компания "Пупкин и Ко". Я продаю автомобили, и у меня есть своя база данных, где фиксируются все покупки. Скажем, раз в месяц я обязан предоставлять данные в ГАИ (или еще куда то), в требуемом ими формате. Какое самое удобное средство для установления однозначного соответствия между Ивановым Иваном Ивановичем в моей базе, и Ивановм в ГАИ-шной? Конечно же, уникальный идентификатор.
***С т.зр. надежности лучше организовать поиск по локальным БД, а не сливать все в одну кучу.***
Ну скажете тоже...
Ну и опишите мне тогда процесс, каким образом будет происходить поиск по всем "шарашкиным конторам", в частности по базе данных конторы "Пупкин и Ко", у которого база данных по какой то извращенной прихоти тамошнего программиста, реализована на Clipper-е, под DOS, с данными, впихнутыми в одну единственную таблицу. А в другой мега-конторе, на тыщщу человек, есть какая то всеобщая супер-пупер глобальная БД, на Оракле, написанная "по всем понятиям" и архитектуру которой уже с трудом понимают сами разработчики?
Лично я, такой поиск представляю с трудом :)))
***Классическое решение - это ФИО и проч. Глобальный id - как раз "собачья пятая лапа".***
У вас довольно необычный взгляд, на классические решения...
Скажите, и часто у вас в компании применяют такие вот "классические решения"? :))) Или же все же предпочитают пользоваться "пятой лапой"? То бишь - IDшником? :)
***Просто таким id и призван быть ФИО и проч. Я к тому говорю, что для компьютера все равно (ФИО+др+мр или id), а для человека - нет.***
Мы начинаем ходить по кругу. Я уже приводил вполне определенные аргументы "против" такой идентификации. А вы пока что просто настаиваете, что ФИОдрмр - лучше. (Утверждние, "так надежнее", пока что не является аргументом, потому что вы так и не пояснили, ЧЕМ ЖЕ именно надежнее)
***Так это и есть недоверие к контролирующим. Ведь (в рамках приведенного примера) перед женой/ полюбовницей Вы подобного негодования испытывать не будете.***
Сравнили...
***Интересно, что Вы не обращаете на воспитательное значение id взамен ФИО. Ведь даже в быту, желая показать уважение к человеку, называют его по имени-отчеству.***
Ну, мы ведь в основном обсуждали взгляд на эту проблему с точки зрения программеров, не так ли?
А как программера, меня абсолютно не волнует ни "воспитательный", ни "надзидательный", ни какой либо еще аспект. Есть задача, есть пути ее решения, есть ограничения. Одним из них является удобство юзера. ("Воспитательными" моментами - пусть маркетинг занимается. Ему за это деньги плотют :)))) )
С технической точки зрения, использование ID - более удобно и обоснованно, чем остальные данные. Весомых контр-аргументов вы не привели, что не удивительно. Что бы найти аргументы в пользу чего то другого - нужно очень хорошо постараться :)))
С точки зрения удобства, свое личное мнение я тоже высказал. Лично мне, удобнее пользоваться пластиковой картой с ID, чем таскать паспорт.
Свою, чисто человеческую точку зрения на эту идею, я тоже излагал
А вот с точки зрения "воспитательного значения"... Тут я вообще не понимаю о чем речь...
Никто, никого не собирается называть по номерам. Если вы придете устраиваться на работу, и HR, сверившись с документами, скажет вам - "Здравствуйте, миллионстотысячтристсемидесятый миллионтреставосемьдесяттысячсемьдесятседьмович!", то я съем свою мышь вместе с разъемом и PS2 адаптером :)))
***С учетом интенсивного развития нанотехнологий подобные способы воздействия на человека через десяток лет могут оказаться не такой уж фантастикой.***
Сергей, я свои соображения по этому поводу изложил в сообщении Артуру.
Тут, добавлю лишь, что вот когда это перестанет быть фантастикой, тогда и можно будет вести конструктивный разговор. А так, можно дойти до опасений, что этот чип откроет портал и телепортирует неугодных на Марс :)
Ну... мало ли... Сейчас это фантастика, а лет через 10 перестанет ей быть :)))
***А вот и нет. Вы просто не в курсе. Воздействуя на Вас например импульсами с частотами близкими в альфаритмам, можно вызвать Вашу дезриентацию. Есть частоты вызывающие эйфорию, есть вызывающие страх или сексуальную активность. Всё это давно известно.***
Ну, разве что на таком грубом уровне...
Я в этом деле дилетант, и на мой дилетантский взгляд, тут возникает ряд вопросов. О воздействии частот, факт действительно хорошо известен. Но тут возникает вопрос о том, какими путями будут передаваться частоты? Ведь для это чип нужно будет не просто имплантировать, но и соединить с нервной системой, что само по себе намного сложнее. Допустим это сделали. Но предполагается, что чип будет имплантироваться в руку, а в руке все нервные окончания, насколько мне известно, отвечают именно за простейшие функции, связанные с руками и, вроде как, не имеют связей с теми участками мозга, которые ответственны за функции более высокого порядка. Таким образом, появляется возможность манипуляции частотами, только за счет "игр" с тактильными ощущениями в руках. Кстати, еще не факт, что какие нить "странные ощущения" появляющиеся в руках с периодичностью в 5 Гц (помоему именно на этой частоте возникает ощущение страха) будут иметь тот же эффект, как воздействие манипуляциями со светом или звуком с той же частотой.
Но, допустим, что это тоже сработало. Но воздействие должно быть скрытым, именно в этом вся сила. А так, любой поймет, что в данный момент, на него воздействуют.
Впрочем, я не спец по этому вопросу. Интересно, что скажут люди, имеющие профессиональное отношение к данному вопросу...
Это во-первых.
Во-вторых: А почему Вы решили, что я сторонник "чипизации"? :)
Лично мне, конечно, с одной стороны нравятся те преимущества, которые может дать "чипизация". Но с другой стороны, меня вовсе не радует, еще более широкая возможность тотального контроля, плюс наличие непонятного, "черного ящика" в организме. Кроме того, во мне издавна есть какое то категорическое неприятие (на уровне инстинкта) того, что бы в моем теле находился какой то инородный предмет. Например, мне весьма нравится пирсинг (в разумных пределах) но... на других :) При одной только мысли, что мне продырявят ухо, и проденут туда какой нить кусок металла - меня аж передергивает :)))
Так что я, скорее противник "чипизации", чем сторонник. Другое дело, что я пытаюсь отделить для себя реальные угрозы от страшилок и предрассудков.
Но нужен, что бы заносить эти бумаги в базу.
В случае краша что ли? Id же будет присваивать машина, а не человек. Человек буде вносить ФИО и проч. А машина "обзывать" своим машинным именем. Или я не прав?
Ну просто представьте себе задачу и более менее подробно представьте себе реализацию решения.
Представляю. И особой необходимости в глобальном id не вижу.
Как, например, из разных баз сливать информацию в одну.
С т.зр. надежности лучше организовать поиск по локальным БД, а не сливать все в одну кучу.
Мне вообще весьма удивительно, что приходится коллегу убеждать в удобстве независимого, уникального идентификатора для данных, разбросанных по разным базам.
Просто таким id и призван быть ФИО и проч. Я к тому говорю, что для компьютера все равно (ФИО+др+мр или id), а для человека - нет.
Это ведь классическое решение. Никто ничего нового не придумал!
Классическое решение - это ФИО и проч. Глобальный id - как раз "собачья пятая лапа". И в конечном счете, от него, возможно, и откажутся. Как только появится чип, сделают "реверанс" в сторону несогласных. Что-типа: ну ладно, id мы тебе присваивать не будем, но взамен ты должен вживить чип. :)
Почему вы так решили? Обоснуйте.
Мне это представляется очевидным и законным шагом перехода к безбумажным технологиям.
Да ну бросьте. Это вполне естественное нежелание ставить кого бы то ни было, о каждом шаге. Кому понравится, если где то будет оседать инфа вплоть до того, какие, я извиняюсь, презервативы он предпочитает? Ну, это конечно утрированно, но все же...
Так это и есть недоверие к контролирующим. Ведь (в рамках приведенного примера) перед женой/ полюбовницей Вы подобного негодования испытывать не будете.
p.s. Интересно, что Вы не обращаете на воспитательное значение id взамен ФИО. Ведь даже в быту, желая показать уважение к человеку, называют его по имени-отчеству. Id этого начисто лишен. Более того, он человека унижает до положения некоего муравья/ винтика в системе того, кто контролирует глобальную id. Даже уголовная кличка апеллирует к личности.
===Вживляемые чипы позволяют не только собирать информацию о Вас, но и генерировать сигналы, воздействующие на внутренние системы Вашего организма.====
А вот и нет. Вы просто не в курсе. Воздействуя на Вас например импульсами с частотами близкими в альфаритмам, можно вызвать Вашу дезриентацию. Есть частоты вызывающие эйфорию, есть вызывающие страх или сексуальную активность. Всё это давно известно.
Мой знакомый - конструктор одного из московских НИИ ( непростых ) рассказал мне, что уже давно изучен эффект воздействия на человека мощных световых импульсов определённой частоты. Они вызывают нечто вроде временной эпилепсии у вполне здоровых людей. И установки такие делали....И опробывали. Очень эффективно. Толпу укладывает без всяких водомётов. Ну скуксится правда кто нибудь...не без того.
А тут источник сигнала уже внутри Вас будет.
Не боитесь, что чип превратит Вас в куклу? Хотя многие не боятся....по некомпетентности в основном. Но Вы то должны понимать....Нет?
Может быть, на сегодняшний день это и не доведено до серийного производства. Но опыты такие активно проводятся. Об их успешных результатах были неоднократные публикации. Там, правда, речь пока идёт о крысах. Но всё начинается с крыс.
С учетом интенсивного развития нанотехнологий подобные способы воздействия на человека через десяток лет могут оказаться не такой уж фантастикой.
***Для кого вводится это удобство? ДЛЯ нас с Вами? Или для спецслужб ПРОТИВ нас с Вами?***
Это как топор. Один дрова рубит, другой головы. Так и здесь - есть варианты использования и ДЛЯ, и ПРОТИВ.
Как я уже говорил, как программист, я идею одобряю. Как человека - она меня, мягко говоря, настораживает. Именно потому, что ожидаю вариантов использования "против".
***Люди таким образом уподобляются биороботам....
Вживляемые чипы позволяют не только собирать информацию о Вас, но и генерировать сигналы, воздействующие на внутренние системы Вашего организма.
***
Это уже фантастика. Примерно то же самое, как если бы кто то говорил о возможности внести вирус в компьютер, путем подключения спец-устройства в соседнюю розетку.
