MySQL: сложное структурирование и запрос данных

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

location 1 (location_group_name, owner_id, admin_id) 
    location 1.1 (name, address) 
    location 1.1.1 (name) 
     // DEVICE LIST 
     device 1 (manufacturer_id, model_id, serial, purchase_date, service_date) 
      Battery (manufacturer_id, model_id, purchase_date, service_date) 
      Accesory 1 (manufacturer_id, model_id, purchase_date, service_date) 
      Accesory 2 (...) 
      Accesory n (...) 
     device 2 
      Battery 
      Accesory 1 
      Accesory 2 
      Accesory n 
     device n 

     // STAFF LIST 
     person 1 (name, email) 
      qualification 1 (type, date) 
      qualification 2 (...) 
      qualification n (...) 
     person 2 
     person n 
    location 1.1.2 
    location 1.1.n 
    location 1.2 
    location 1.n 
location 2 
location n

В настоящее время я думал вставив каждое устройство и человек как упорядоченный многомерный массив, но я не уверен, насколько хорошо это будет работать из-за того, что скрипт хрон будет проверять service_date поля каждый и отправлять автоматические письма администраторам и владельцам групп местоположений, если выполняются определенные критерии. Чтобы усложнить ситуацию, данные устройств должны быть доступны для поиска в model, а также в случае отзыва или serial_number для быстрого поиска, если у пользователя есть много устройств, которые добавлены и/или точно не знают его местоположение.

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

Также, если вам нужна дополнительная информация, пожалуйста, не стесняйтесь спрашивать, и я с удовольствием разработаю.

Заранее благодарю вас, любой ввод будет более чем оценен!

источник

2010-08-06 Valentin Flachsel

Всегда ли будут ровно 3 уровня местоположения? Возможно, получите белую доску и начните рисовать отношения, которые, по вашему мнению, вам нужны (а затем итерации по ней, ища проблемы). – ircmaxell

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

Я не эксперт по SQL, и я создал менее десяти приложений на базе баз данных, но я не вижу необходимости запрашивать здесь внутренние циклы; ваша структура почти полностью «иерархична» (не уверен, что это официальный термин только для одного родителя). Не могли бы вы рассказать о проблемах, которые вы предвидите? – MvanGeest

Я не совсем уверен, что вы пытаетесь сделать здесь, но почему все иерархии? Это какая-то модель магазина/устройства/сотрудника, правильно? В реляционной базе данных вы можете разделить дискретную информацию на свои собственные разделы и связать их с другими таблицами. Поэтому, если у вас есть магазины/устройства/сотрудники, у вас может быть таблица «магазины», таблица «устройства», таблица «владельцы», таблица «сотрудники», таблица «stores_employees», таблица «owner_stores», Таблица «devices_stores» (и вы могли бы отслеживать инвентарь в этом), таблицу «employees_qualifications» и т. д.

источник

2010-08-06 16:58:37 treeface

+1 Согласен, и 'JOIN' разрешает все возможные запросы здесь, насколько я могу судить.Но поскольку store-> employee - один -> много, вам не нужно будет делать лишние беспорядки, такие как 'stores_employees'. Если вы (@FreekOne) хотели бы, я могу набросать его с помощью Dia и включить некоторые примеры запросов ... – MvanGeest

О, и, пожалуйста, извините меня, если я полностью не понимаю проблему, которая всегда возможна ... – MvanGeest

+ 1 от меня тоже, как было сказано в моем вопросе, я сделал столько же, что нужны были, и это то, что я искал, единственная проблема заключалась в том, что я никогда не делал ничего сложного, как это, и я не очень знайте, с чего начать. Иерархия фактически показывает, как информация будет представлена в интерфейсе, что на самом деле очень важно из-за огромного количества данных, которые потенциально могут отображаться. MvanGeest: если бы вы могли это сделать, я был бы более чем благодарен! –

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

Не волнуйтесь о запросах в цикле. С подготовленными заявлениями они не должны быть такими медленными.

источник

2010-08-06 16:54:45

MySQL: сложное структурирование и запрос данных

ответ

Смежные вопросы