Столбцы номера телефона в базе данных
NullPointerException s - исключения, возникающие при попытке использовать ссылку, которая указывает на отсутствие местоположения в памяти (null), как если бы она ссылалась на объект. Вызов метода по нулевой ссылке или попытка получить доступ к полю нулевой ссылки вызовет функцию NullPointerException. Они наиболее распространены, но другие способы перечислены на странице NullPointerException javadoc.
Вероятно, самый быстрый пример кода, который я мог бы придумать для иллюстрации NullPointerException, be:
public class Example {
public static void main(String[] args) {
Object obj = null;
obj.hashCode();
}
}
В первой строке внутри main я явно устанавливаю ссылку Object obj равной null. Это означает, что у меня есть ссылка, но она не указывает на какой-либо объект. После этого я пытаюсь обработать ссылку так, как если бы она указывала на объект, вызывая метод на нем. Это приводит к NullPointerException, потому что нет кода для выполнения в местоположении, на которое указывает ссылка.
(Это техничность, но я думаю, что она упоминает: ссылка, которая указывает на null, равна 't то же, что и указатель C, указывающий на недопустимую ячейку памяти. Нулевой указатель буквально не указывает на в любом месте , который отличается от указаний на местоположение, которое оказывается недопустимым.)
8 ответов
Быстрый тест: Вы собираетесь добавлять/вычитать/умножать/делить Номера телефона? Нет. Так же к SSNs, Номера телефона являются дискретными частями данных, которые могут содержать фактические числа, таким образом, строковый тип является, вероятно, самым соответствующим.
одна точка с хранением номеров телефона является продвижением 0.
, например: 01202 8765432
в международном столбце, этот 0 будет разделен, который делает номер телефона недопустимым.
я рисковал бы предположением в - подкачиваемый для пробелов, то, потому что они ничего на самом деле не имеют в виду
, например: 123-456-789 = 123 456 789 = 123456789
Лично, я не разделил бы символов, как в зависимости от того, где номер телефона от, это могло означать разные вещи. Оставьте номер телефона в точном формате, он вводился, поскольку, очевидно, это - путь человек, который ввел его, привык видеть его.
Действительно не имеет значения, как Вы храните его, , пока это последовательно . Норма должна разделить символы форматирования, но можно также сохранить код страны, код области, обмен и расширение отдельно, если у Вас есть потребность запросить на тех значениях. Снова, требование - то, что это последовательно - иначе запросы, это - ЛАВАШ.
Я решил бы сохранить цифры как строку и добавить различное" ()" и "-" в моем коде дисплея. Это действительно становится более трудным с международными номерами. Мы обрабатываем его при наличии различных "интернационализировавших" форматов отображения в зависимости от страны.
То, что мне нравится делать, если я знаю, что номера телефона только будут в определенном регионе, таком как Северная Америка, должно изменить запись в 4 поля. 3 для кода области, 3 для префикса, 3 для строки, и возможно 5 для расширения. Я затем вставляю их как 1 поле с '-' и возможно 'e' для обозначения расширения. Любой поиск, конечно, также должен следовать за тем же процессом. Это гарантирует, чтобы я получил более регулярные данные, и даже позволяет, чтобы число использовалось для того, чтобы на самом деле выполнить телефонный звонок, когда-то - и расширение удалены. Я могу также возвратиться в исходные 4 поля легко.
Разделение некоторых символов и разрешение других могут оказать влияние, если таблица базы данных собирается управлять другой системой, например, какой-то IP-телефонией. В зависимости от включенных систем может быть законно иметь и т.д. 333 как суффикс, тогда как разработчики не могли объяснить "-" в строке (и да, я предполагаю здесь...)
Что касается хранения как varchar, а не интервал, это - просто-ole здравый смысл мне. Как упомянуто прежде, начальные нули могут быть разделены в международном поле, запрос на международном поле может выполнить неявные математические функции (который мог также объяснить разделение "-" из текста, Вы не хотите входить 555-1234, и это сохранило, поскольку-679 делают Вас?)
Короче говоря, я не знаю точное обоснование, но могу вывести некоторые возможности.
Хороший материал! Кажется, что основной момент - то, что форматирование номера телефона не является на самом деле частью данных, но является вместо этого аспектом исходной страны. Однако, путем хранения дополнительной части числа, как, можно было бы повреждать модель разделения форматирования от данных. Я сомневаюсь, что все страны используют тот же синтаксис/формат для описания расширения. Кроме того, если интеграция с телефонной системой является (возможным) требованием, затем могло бы быть лучше сохранить расширение отдельно и создать сообщение, как это ожидается. Но Mark также делает правильное замечание, что, если Вы последовательны, затем, вероятно, не будет иметь значения, как Вы храните его, так как можно запросить и обработать его последовательно также.
Спасибо Eric для ссылки на другой вопрос.