Как стать автором
Обновить
0
0
Вячеслав @niga

Пользователь

Отправить сообщение
На сайте издательства «Манн, Иванов и Фербер» (не реклама) давно реализован похожий способ аутентификации.
По поводу истории страны согласен. Изначально считал, что там будет храниться только код. Без названия страны. old_code и new_code — коды до и после изменения. Согласен, что это не очень правильно. Ваш вариант правильней.

Каким образом можно отследить распады и соединения стран? У меня только одна идея: путём создания/удаления и изменения записей.

Давайте продолжим. Мне достаточно интересно.
В схеме нет адреса. Давайте пока вообще о нём забудем. И таблицу регионов удалим. Сделаем такую небольшую подсистему телефонных номеров. И отдадим в пользование. Потом сделаем подсистему адресов и будем связывать.
Мне не кажется, что в схеме есть адрес. В схеме есть привязка телефона к населённому пункту. Населённый пункт помимо привязки к стране имеет привязку к региону/краю/району/etc, которые можно объединить в одну таблицу.

Даже если смотреть на это как на схему, то поставьте себе задачу получить код того же населённого пункта Александровка.
Я с радостью сделаю схему и для адресов. Отдельно. Я хочу сделать подсистему отдельно, но правильно. С возможностью дальнейшего роста.
Я не совсем с Вами согласен по поводу region.

Данная база имеет информативность стремящуюся к нулю. Из неё мы можем узнать только информацию о смене кодов для телефона. По хорошему из неё было бы не плохо получить информацию о владельце номера. Я не говорю сейчас про адрес. В этом случае без таблицы region есть шансы получить номера для 166-ти жителей Александровки (при наличии в каждом населённом пункте однофамильцев). И это только для России.

Таблица locality не должна содержать информацию о мобильных операторах. Только населённые пункты. Для мобильных операторов необходимо создать дополнительную таблицу. И связать её с locality_code. На данный момент все коды мобильных операторов, как и городские коды, хранятся в locality_code.

По поводу длинны кода для населённого кода согласен. Самый длинный телефонный код (как минимум для России) принадлежит селу Средние Пахачи (Камчатка). Состоит из 8-ми символов: 41544513.

Немного доделал схему: content.screencast.com/users/nigasam/folders/Jing/media/a0148b59-5da8-43be-9a09-2614bcd10341/00000004.png

Для каждого кода теперь указывается идентификатор оператора. Городской номер также должен ссылаться на эту таблицу.

Давайте продолжим. Эта тема интересна мне.
locality — населённый пункт, сначала думал назвать city, но это не верно.
locality_code — коды номеров, которые присутствуют в населённом пункте.

region введён для понимания о каком населённом пункте идет речь. К примеру, населённый пункт Александровка присутствует на карте России 166 раз: ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B0%D0%BD%D0%B4%D1%80%D0%BE%D0%B2%D0%BA%D0%B0

Остальные сущности, надеюсь, понятны.

Про историю согласен. Должна быть информация только о замене кодов. Соответственно таблица для кодов стран и кодов населённых пунктов.
Не добавил в базу информацию о типе телефона (мобильный/домашний), но получилось что-то вроде этого: content.screencast.com/users/nigasam/folders/Jing/media/940fcf20-7000-499c-8b2e-d35a63dc506e/00000003.png
Укажите, пожалуйста, на неточности.
Спасибо!
Спасибо! Заказал.
Спасибо, заказал.
А я рад тому, что я отдал свой голос и приложил свою руку к регулированию той свободной зоны, которая у нас осталась.
Минусуйте господа «правообладатели». Поставил ссылку на слово «правообладатели»: habrahabr.ru/post/189274/#comment_6572870 Но не хватило кармы.
Случайно нажал кнопку «Воздержаться».
Отдаю голос за «Я подписал петицию и согласен со всеми данными предложениями».
Очень жаль, что нет возможности проголосовать заново.
rawme.ru/raw/1
Вероятно стоит округлять выдержку до 1/200 и диафрагму до десятых.
payments (id INT, uid INT, pay_date DATETIME, amount DECIMAL(15, 2))

Я один вижу в этой таблице тип DATETIME?
Единственное, что я не воспроизвёл в своей таблице, так это тип поля amount, но оно в данном случае не играет роли.
Насколько я помню, MySQL не использует индексы в подзапросах.
После ON следует условие для выборки из связанных таблиц в случае JOIN.
По моему GROUP BY не допустит этого.
Падения были дважды. А вот списаний не было.

Информация

В рейтинге
Не участвует
Откуда
Россия
Дата рождения
Зарегистрирован
Активность