Как лучше спроектировать БД под телефонный справочник?

7489098

Нужно спроектировать одну несложную реляционную базу данных - телефонную книгу, причем, естественно, так, чтобы она повторяла функциональность любого телефонного справочника в любой из созданных моделей телефонов.
Собственно, вопрос заключается в том, чем плоха такая структура базы данных и как ее можно улучшить:
в базе 3 таблицы, первая содержит поля manID - индекс человека, занесенного в справочник, и manName - его имя; вторая содержит поля numberID - идентификатор конкретного телефона, basic_digit - цифры номера без префикса, prefix1, prefix2, prefix3 - возможные префиксы номера, типа +7, 8, +7495; третья таблица содержит связи между ними, а именно поля manId и numberID
Вроде, первые 3 нормальные формы в каждом отношении присутствуют.
Итак, чем плохо такое решение и как его можно улучшить?

katrin2201

непонятно зачем тебе связь многие ко многим между телефонами и людьми
то что у человека много телефонов это очевидно
а вот то, что у телефона много людей - такого ни в одном телефонном справочнике не видел
плюс непонятен смысл отдельного хранения префиксов, если они появились в результате нормализаций, то это явный перебор имхо
в остальном, тут все настолько просто, что можно долго не думать
предложеный вариант будет уже вполне юзабельным

Boris1980

Для каких целей и пользователей база не сказал.
Я бы немного параметризовал категории телефонов:
- тип телефона (мобильный, домашний, рабочий)
- используется/не используется
- публичный/личный
- комментарий (например, "звонить с 9 до 18")
Если в базе партнеров будут юр.лица, то добавил бы еще одно поле, скажем "категория телефона" (ресепшн, факс, бухгалтерия, отдел. кадров, ген. дир, ну и .т.д. мысль понимаешь)
С префиксами, идея не понятна, хотя можно каждый номер раскладывать в несколько полей: Страна-Код города-Номер-добавочный.
В принципе, таблиц с данными должно быть две-три, плюс справочники.

VitMix

Собственно, вопрос заключается в том, чем плоха такая структура базы данных ... поля manID - индекс человека ... и manName - его имя

Эта структура плоха (а вернее, ужасна) своей вопиющей неполиткорректностью, так как она дискредитирует женщин! Срочно переименуй поля в personID и personName соответственно, пока феминистки не увидели!

Helga87

а твое предложение дискредитирует российскую милицию! Потому что милиция — это не человек, это много людей! Надо срочно переименовать в ContactID и ContactName

7489098

собственно, тут такой вопрос возник. непонятно, как вообще быть с префиксами, которые представляют коды страны, города. например, в телефонной книге есть запись 89261234567, а входящий звонок распознается оператором сотовой связи как +79261234567. или в книге есть абонент 8<внутренний по стране код города><номер абонента>, а звонок распознается как +7<международный код корода><номер абонента>.
непонятно, как в этих случаях осуществляется распознавание номера: в базе данных должно лежать какое-то соответствие префиксов или оператор телефонной связи при входящем звонке должен присылать такое соответствие?
Если в базе данных, то как должна выглядеть соответствующая таблица?

Boris1980

Ты какую задачу-то в итоге решаешь? Типичный пример "легкой, простенькой" задачки с базой данных на две таблички.
По поводу форматов итогового набора цифр при звонке, нужно заботать матчасть по логике обработки проходящих через телефонную станцию звонков. Азы, чтоб разговор поддержать знаю, но для прикладных задач нужен уже документ с перечислением стандартов и правил.

Garryss

непонятно, как в этих случаях осуществляется распознавание номера: в базе данных должно лежать какое-то соответствие префиксов или оператор телефонной связи при входящем звонке должен присылать такое соответствие?

Думаю, что в базе должны храниться телефонные в международном формате, а если где-то используются другие варианты (как эта восьмерка то прямо вшить в код правила преобразования.