Как Вы имеете дело со “Многими Именами 1 Человека”?
это работает для данного формата
$ awk '/^#/ {next}
/^export/ {n=split($2,a,"="); if(a[2]=="") next; kv[a[1]]=a[2]; print $2}
/^let/ {split($2,a,"[[110]]"); if(a[2] in kv) print a[1] kv[a[2]]+a[3]}' file
BASE_PORT=8000
WEB_HOST=https://microsoft.com
DB_DRIVER=org.postgresql.Driver
APP_ROOT=$HOME/myapp100
JMS_STORE=$APP_ROOT/../jms
JMS_PORT=8425
HTTPS_PORT=8401
USE_CRED=yes
6 ответов
Пока у Вас есть уникальный идентификатор для каждого пользователя (который не является их именем), у Вас может быть таблица, которая отображает изменения имени на уникальный идентификатор, и затем свяжите каждое сообщение с тем уникальным идентификатором.
(Table mapping names to UIDs) Name UID Robert S 123456 Bob S 123456 Bert S 123456 Darren 987654
(Table with post information, including author's UID) Title Author ... Post 1 123456 Post 2 123456 Post 3 987654
(Table with author information) UID Preferred Name Webpage ... 123456 Robert Smith http://www.robert.com 987654 Darren Jones http://www.jones.com
Это - вероятно, хорошая идея принять только одно имя от Вашего пользователя и позволить им "псевдоним" или "общедоступное имя". Это дает им свободу иметь официальное имя, возможно, для отправки по почте или тарификации и общедоступно-видимого названия взаимодействия на Вашем сайте.
Кроме того, я не думаю, что позволил бы моим пользователям иметь несколько имен, если моя система не потребовала его. Если я сделал, я разделил его на две таблицы:
Пользователи:
- идентификатор пользователя (исключая: 1821)
UserNames:
- идентификатор пользователя (исключая: 1821)
- firstName (исключая: Jonathan)
- lastName (исключая: Sampson)
Кроме того, Вы могли включить поле usernames таблицу называют'isPrimary'. Это было бы булевым значением, которое скажет Вам который имя рассматривать как основное имя пользователя. Это подобно как хранилище Википедии история данных/изменений. Они сохраняют все, но метка, которая "активна", или в Вашем "основном" случае.
Это звучит мне как Вы, пытаются использовать их имя в качестве первичного ключа или UID. Это - неправильный способ пойти. У Вас должен быть отдельный UID как первичный ключ, затем имя может быть тем, что Вы хотите, и у Вас может даже быть список альтернативных названий.
Я соглашаюсь с первыми 3 сообщениями о том, как структурировать Вашу схему.
В отношении UI я позволил бы поле для людей, законных первый, средний и lastname, который должен изменяться очень редко.
Затем позвольте псевдоним (псевдонимы) в зависимости от своих требований к приложению.
Наличие их полного официального имени может пригодиться для ситуаций с тарификацией/финансовым/HR также.
Настоящая проблема происходит, когда у Вас есть несколько приложений, и у каждого есть их собственная схема для получения информации о пользователе. Система расчетов могла бы иметь "Will Smith"; система начисления заработной платы могла бы иметь "William Smith"; система требований могла бы иметь "Willie X. Smith". Все - действительно тот же человек.Чем Вы занимаетесь? Это - огромная проблема для дымохода, приложений прежней версии.
Вы могли всегда делать таблицу AKA, где у Вас могло быть предпочесть имя к иначе имени. Таким образом, если кто-то использует счет имени, можно всегда заменять его William.
Я лично никогда не использовал это понятие для имен, но я действительно поддерживаю проект, который делает что-то похожее с Названиями фильмов, которые могут, варьировался для разных стран.