2013-10-24 5 views
0

Я был бы признателен за совет по следующим вопросам:Рекомендации по проектированию оптимальной базы данных

Я беру над базой данных оценки для учеников, часть того, что я должен сделать, это переместить его из среды ЛАМПЫ (MySQL) для Windows Azure (MS SQL).

В настоящее время структура базы данных использует одну запись для ученика, проблема заключается в том, что каждый ученик имеет 144 поля для оценочных данных (поскольку мы говорим о 4 предметах, оцениваемых 6 раз в год в течение 6 лет).

Операция по ведению домашнего хозяйства, которая предусматривает работу с каждым учеником и копирование оценок между столбцами, разумно работает в MySQL, но занимает много времени или останавливается в MS SQL, даже после перехода на использование PDO и подготовленных операторов.

мне интересно, будет ли лучше дизайн будет иметь таблицу оценки со следующей структурой:

ид | PupilId | Тема | Год | Срок | Оценка

Буду благодарен за любые мысли о том, является ли это более эффективной структурой.

Stephan

+0

все, что начинается с работы через каждый зрачок, звучит как курсорный курсор, что очень плохо. вам нужно подумать о промежутках наборов данных. – HLGEM

+0

В большинстве баз данных SQL обычно лучше разбивать таблицы со многими столбцами на несколько таблиц. Это не на 100% верно, но только по моему опыту. Это позволяет упростить расширение (вам не нужно добавлять новые столбцы, если вы хотите добавить больше данных, только новые строки) и, как правило, это более чистое решение. –

+0

Структура, о которой вы указали, может работать пока.но лучшая схема может быть эффективно разработана, если мы знаем, как она будет доступна. вы можете привести пример примерного запроса, может быть на простом английском языке, как будут запрашиваться данные. Также вы упомянули, что текущая структура базы данных содержит 144 столбца. это одна таблица. как насчет других таблиц. Я имею в виду, что должно быть больше таблиц, описывающих больше атрибутов объектов Учеников, Субъектов и/или Оценки, правильно? –

ответ

0
>assessments 
> id   unsigned int(P) 
> pupil_id unsigned int(F pupils.id) 
> subject_id unsigned int(F subjects.id) 
> score  double 
> term  unsigned int 
> year  unsigned int 
> 
>+----+----------+------------+-------+------+------+ 
>| id | pupil_id | subject_id | score | term | year | 
>+----+----------+------------+-------+------+------+ 
>| 1 |  1 |   1 | 100.0 | 1 | 2013 | 
>| 2 |  1 |   2 | 92.3 | 2 | 2013 | 
>| 3 |  1 |   3 | 78.9 | 2 | 2013 | 
>| .. | ........ | .......... | ..... | .... | .... | 
>+----+----------+------------+-------+------+------+ 
> 
>pupils 
> id    unsigned int(P) 
> first_name  varchar(20) 
> last_name  varchar(20) 
> ... 
> 
>+----+------------+-----------+-----+ 
>| id | first_name | last_name | ... | 
>+----+------------+-----------+-----+ 
>| 1 | Stephen | Essex  | ... | 
>| .. | .......... | ......... | ... | 
>+----+------------+-----------+-----+ 
> 
>subjects 
> id    unsigned int(P) 
> name   varchar(20) 
> 
>+----+-----------------+ 
>| id | name   | 
>+----+-----------------+ 
>| 1 | Physics   | 
>| 2 | Calculus I  | 
>| 3 | Ancient History | 
>| .. | ............... | 
>+----+-----------------+ 

Именно так я бы начал нормализовать структуру, основанную на описании таблицы op. Важно помнить, что любая база данных может перемещать целые индексы намного быстрее и с меньшими затратами, которые могут анализировать строковые данные, даже если они индексированы. Я бы поднял этот ответ, если мог.

0

Ваша предлагаемая структура не имеет смысла. Вы заменяете 144 поля на один? HOw вы собираетесь запрашивать эти поля?

SQL-сервер работает быстро, я подозреваю, что ваша текущая реализация либо зацикливается на записях, либо отсутствуют индексы.

+0

На данный момент 144 столбца названы так: Yr1Aut1Reading - i.e Year 1, Autumn 1, Reading. В моей предложенной таблице я использовал столбцы Subject, Year и Term, чтобы определить, для чего предназначена оценка, и когда, а затем колонку «Оценка», чтобы привести результат. –

0

То, что я думаю, что вы описываете, это именно то, что я хотел бы сделать:

assessments 
    id   unsigned int(P) 
    pupil_id unsigned int(F pupils.id) 
    subject_id unsigned int(F subjects.id) 
    score  double 
    term  unsigned int 
    year  unsigned int 

+----+----------+------------+-------+------+------+ 
| id | pupil_id | subject_id | score | term | year | 
+----+----------+------------+-------+------+------+ 
| 1 |  1 |   1 | 100.0 | 1 | 2013 | 
| 2 |  1 |   2 | 92.3 | 2 | 2013 | 
| 3 |  1 |   3 | 78.9 | 2 | 2013 | 
| .. | ........ | .......... | ..... | .... | .... | 
+----+----------+------------+-------+------+------+ 

pupils 
    id    unsigned int(P) 
    first_name  varchar(20) 
    last_name  varchar(20) 
    ... 

+----+------------+-----------+-----+ 
| id | first_name | last_name | ... | 
+----+------------+-----------+-----+ 
| 1 | Stephen | Essex  | ... | 
| .. | .......... | ......... | ... | 
+----+------------+-----------+-----+ 

subjects 
    id    unsigned int(P) 
    name   varchar(20) 

+----+-----------------+ 
| id | name   | 
+----+-----------------+ 
| 1 | Physics   | 
| 2 | Calculus I  | 
| 3 | Ancient History | 
| .. | ............... | 
+----+-----------------+ 
0

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

PupilId | S1_Y1_T1_Assessment | S2_Y1_T1_Assessment | ... | S4_Y6_T6_Assessment 

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

Если текущая таблица делает хранит данные зрачка, я отделяю это от другой таблицы.

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