2009-10-19 1 views
0

Я пытаюсь создать приложение, которое будет принимать данные MLS (Multiple Listing Service) недвижимости из CSV и вставить его в базу данных. У меня есть синтаксический анализ CSV, но у меня проблемы с эффективностью базы данных. Проблема в том, что поставщики данных MLS, как известно, быстро меняют формат элементов свойств без особого внимания. Поэтому наличие одной таблицы, которая соответствовала бы данным 1to1 с данными, может вызвать проблемы с загрузкой данных в будущем.Схема базы данных MLS

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

id = int 
property_id = longint 
element_key = char 
element_value = text 

Как вы можете себе представить, что это очень медленно, с 1000s свойств около 80+ элементов каждый.

Как я могу сделать это более эффективным, но сохранить базу данных гибкой?

И да, я знаю о memcache и планирую использовать его.

ответ

1

Вы находитесь во власти поставщиков данных, если только нет способа привести их под контроль. Это было проклятие работы с базой данных в течение примерно пятидесяти лет, и это вряд ли изменится в ближайшее время. Использование CSV имеет мало общего с основной проблемой.

Я подозреваю, что это не только формат данных, которые меняются, но и семантика данных, даже если вы этого не сказали.

Лучше всего иметь одну или несколько промежуточных таблиц, которые будут записывать данные CSV в значительной степени в том виде, в котором вы его получите. Будьте готовы изменить эти таблицы, когда поставщики меняют вещи на вас. Затем напишите некоторые процедуры, которые преобразуют эти данные в подходящую форму для ваших базовых таблиц и копируют преобразованные данные в базовые таблицы. Эти процедуры потребуют периодического обслуживания, но ваши базовые таблицы будут оставаться более стабильными, если вам не нужно добавлять больше возможностей для хранения информации, чтобы соответствовать изменениям, предлагаемым поставщиками.

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

+1

В качестве альтернативы, если схема очень динамична, хранилище данных NoSQL, вероятно, будет иметь больше смысла, чем EAV - такая же мощность, меньше накладных расходов (но, конечно, большинство из тех же проблем) – Tao

+0

Хороший комментарий о проблемах целостности данных в так называемой модели EAV. http://stackoverflow.com/a/4843859/369278 –

0

Это действительно зависит от того, что вы хотите делать с данными. Для вас может быть достаточно базы данных в стиле документа и полнотекстового индексатора (на самом деле, только постоянная форма memcache). Вы просто сохранили бы все данные элемента в одной строке/документе и распакуете его, когда вам это нужно.

Возможно, некоторые вещи here могут быть полезны.