Как спроектировать базу данных MySQL для сервиса на основе почтового индекса? - PullRequest
0 голосов
/ 27 мая 2011

Я пытаюсь создать базу данных MySQL для хранения пользовательских настроек почтового индекса для предоставления определенной услуги. Например, пользователь A, который является водопроводчиком, готов отправиться в почтовые индексы x, y и z, чтобы предоставить свою услугу. Я думал о различных способах реализации этого, и масштабируемость очень важна. Кроме того, я хотел бы иметь соответствие между почтовым индексом и названием города.

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

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

В любом случае, я был бы признателен за любые мысли, идеи или альтернативные проекты, которые могли бы помочь мне в этом. Вопрос действительно сводится к тому, как мне это спроектировать и почему?

Обновление: У меня есть отдельная таблица с информацией о пользователе. Я пытаюсь спроектировать таблицы для предпочтений почтового индекса пользователя.

Ответы [ 5 ]

1 голос
/ 27 мая 2011

Поскольку торговцы обычно не преодолевают сотни миль, чтобы устранить утечку, вы можете подойти к проблеме следующим образом:

Я просто создам таблицу zip_code_distances и предварительно вычислю расстояние междувсе почтовые индексы 42K в США, которые находятся в радиусе 20-25 миль друг от друга .... Только включение почтовых индексов в радиусе 20-25 миль друг от друга уменьшает количество строк, которые необходимо сохранить в таблице расстояний, отмаксимум 1,7 миллиарда (42K ^ 2) - от 42K до более управляемых 4 миллионов или около того ...

Смотрите мой полный ответ здесь:

Рассчитать расстояние междупочтовые индексы и пользователи

Другие таблицы, которые вы бы включили, были бы: city, city_to_zipcode и т. д. ...

Надеюсь, это поможет:)

1 голос
/ 27 мая 2011

Вы должны определять сущности независимо от масштабируемости, в первую очередь вы не хотите делать ошибку проектирования базы данных.Я полагаю, что у вас может быть две таблицы, такие как User и ZipCodes, и таблица, которая будет связывать пользовательские настройки с почтовыми индексами, например UserZipCodes, у которой будет один предпочтительный почтовый индекс или более для пользователя, в зависимости от ваших требований (возможно, принудительное выполнениеэто с уникальным ограничением).Я не знаю, что такое MySQL, но при чтении SQL-сервера такие таблицы с несколькими столбцами не являются проблемой производительности, поэтому лучше проверить их заранее.

1 голос
/ 27 мая 2011

Я бы посоветовал немного улучшить ваш текущий подход.

Используйте базу данных, которая поддерживает индексацию геопространственных данных, например, PostgreSQL с Postgis.Затем, в дополнение к почтовым индексам, сохраните координаты почтового индекса.

Таким образом, когда вы спрашиваете своего сантехника, какие почтовые индексы он хочет обслуживать, вы сможете вытащить ближайшие почтовые индексы.Кроме того, вы сможете вытащить сантехников в близлежащих районах, когда пользователи запрашивают вашу базу данных.

0 голосов
/ 27 мая 2011

Как предлагают другие ... Три объекта: пользователь, почтовый индекс и перекрестная ссылка между ними. Деловые правила были бы ... Пользователь может обслуживать много почтовых индексов. Почтовый индекс может обслуживаться многими пользователями.

Количество строк может показаться большим, но на самом деле это не так уж много для современной СУБД, и есть способы получить очень хорошую производительность из таблиц с миллионами строк. например. Горизонтальная Переразметка.

И было бы неплохо хранить геопространственные данные, чтобы помочь пользователю выбрать близлежащие почтовые индексы в соответствии с предложением @ Denis

0 голосов
/ 27 мая 2011

Я бы использовал postgresql - очень масштабируемый. Это также очень многофункциональный. Что касается схемы, рассмотрите возможность разделения таблицы на три таблицы: 1. таблица почтовых индексов 2. таблица пользовательских данных 3. кросс-таблицы, связывающие почтовые индексы и данные

Не делай этого за одним столом!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...