| nisan |
| Отправлено: 17.05.2004, 14:20 |
|
Не зарегистрирован
|
Люди кпоскажите как лучше поступить.
Надо создать базу данных, так вот можно создать одну таблицу с индексными полями, либо 10 таблиц(разделение большой таблицы), но с двумя полями. Как лучше поступить? |
|
| olegenty |
| Отправлено: 17.05.2004, 15:01 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
а поподробней можно?
| QUOTE | | Как лучше поступить? |
Лучше поступить — как правильно. А правильно — создать реляционную БД. А при создании реляционнй БД несколько по-другому вопрос ставится. Прямо скаж — в корне 
|
|
| nisan |
| Отправлено: 18.05.2004, 05:02 |
|
Не зарегистрирован
|
Ну есть несколько постов , с них беруться данные каждый день( в день 3 раза, время тоже учитываеться), у каждого поста свои типы данные, некоторые типы данных могут совпадать.
Ну вот ключи у меня получаются дата отбора, время отбора, номер поста, это если для большой таблицы, а маленькие если делать, то можно для каждого поста завести отдельную таблицу и тогда там будет только дата и время отбора.
Ну вот и как лучше сделать? |
|
| olegenty |
| Отправлено: 18.05.2004, 06:40 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
две :
1. кодификатор (справочная таблица) — по постам
2. регистрации с постов
потому что если у тебя случайно постов станет 4, ты что, ещё одну таблицу создашь???
|
|
| AVC |
| Отправлено: 18.05.2004, 09:59 |
|
Не зарегистрирован
|
Совсем круто три:
1.Кодификатор постов;
2. Кодификатор параметров (все параметры можно попытаться свести к одному или нескольким типам);
3. Перекрестная таблица Посты*Параметры.
Схема позволяат динамичести наращивать и точки измерений (посты) и измеряемые параметры. |
|
| olegenty |
| Отправлено: 18.05.2004, 10:22 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
да, я упустил, что параметры неидентичны.
тогда всё ещё хуже:
1. Кодификатор постов
2. Кодификатор параметров
3. Спецификация параметров по постам
4. Непосредственно журнал параметров
минусы: параметры придётся хранить как строки, хранить инфу о типе и делать преобразования.
|
|
| AVC |
| Отправлено: 18.05.2004, 10:32 |
|
Не зарегистрирован
|
Да. Забыл о спецификации параметров по постам.
| QUOTE | | параметры придётся хранить как строки |
По собственному опыту знаю, что почти все можно свести к трем типам — строка, число, дата (при большом желании 2 — строка, число). При хранени только строк очень сложно выполнять агрегатные функции. Предпочитаю хранить параметры в столбцах своего типа. |
|
| olegenty |
| Отправлено: 18.05.2004, 11:27 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
Резюме:
4-е таблицы.
Кодификатор параметров вот такой:
ParamID INTEGER; /*Ид. параметра*/
Sign INTEGER; /*условно 0-строка, 1-число*/
NumVal DOUBLE PRESISION; /*Значение, если число*/
StrVal VARCHAR(...); /*Значение, если строка*/
вот так примерно
идеально это делается иначе: через хранение переменной части как XML с XSD типом. кодификатор параметров в этом случае содержал бы XSD тип параметра, а журнал — сам XML. к сожалению — я так не умею...
|
|
| nisan |
| Отправлено: 18.05.2004, 11:55 |
|
Не зарегистрирован
|
А это быстрее будет работать чем посто одна таблица? (а то машинки слабые) |
|
| AVC |
| Отправлено: 18.05.2004, 12:00 |
|
Не зарегистрирован
|
Кодификатор параметра:
ParamID INTEGER; /*Ид. параметра*/
Sign INTEGER; /*условно 0-строка, 1-число*/
можно добавить:
Параметр_Name для удобства при Select'ах
Параметр_Info Описание параметря
Таблица снятых показаний:
Таблица_снятых_показанийID integer PK — не обязательно, но очень удобно в работе
ПостID
ПараметрID
Дата_замера
Значение_для_Double
Значение_для_String
|
|
| Valdemar |
| Отправлено: 19.05.2004, 07:58 |
|
Мастер участка
Группа: Участник
Сообщений: 433
|
| QUOTE | | А это быстрее будет работать чем посто одна таблица? (а то машинки слабые) |
Если у вас все данные будут в одной таблице, то поиск информации будет проходить быстрее, чем если таблица будет нормализована. Но при этом ваша база будет занимать больше места на диске, чем такая же, но нормализованная.
Советую вам почитать о нормализации баз данных. |
|
| AVC |
| Отправлено: 19.05.2004, 08:57 |
|
Не зарегистрирован
|
Одна таблица будет работать быстрее только на нереляционной (или псевдо реляционной СУБД) типа DBF, Paradox и т.д. Если у вас кокой либо sql'евский сервер, то только нормализация. Слабые машины это что <= чем 486? |
|
| nisan |
| Отправлено: 19.05.2004, 11:01 |
|
Не зарегистрирован
|
в среднем P200 |
|
| Gedeon |
| Отправлено: 19.05.2004, 11:44 |
|
Ветеран
Группа: Модератор
Сообщений: 1742
|
| QUOTE (nisan @ 19/05/2004, 12:03) | | в среднем P200 |
Все-таки давайте определимся какая БД. Если это сервер, то что значит в среднем? Если сервер, то перекладывайте всю работу на него, и будет быстро, независимо от клиентов.
|
|
| Valdemar |
| Отправлено: 19.05.2004, 11:54 |
|
Мастер участка
Группа: Участник
Сообщений: 433
|
2AVC
| QUOTE | | работать быстрее только на нереляционной (или псевдо реляционной СУБД) типа DBF, Paradox и т.д. |
Хотелось бы поинтересоваться, что это за зверь такой, псевдо реляционная СУБД. И почему вы считаете Paradox не реляционной СУБД? |
|
| olegenty |
| Отправлено: 19.05.2004, 11:56 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
удручающая ситуёвина (если она на производственном предприятии):
задача поставлена
сроки определены
... а разработчик не ещё не решил, КАК он выполнит работу к СРОКУ.
(это не камень в огород nisana, просто сама постановка задачи разгильдайская, соответственно и камень в огород руководителя nisana)
|
|
| AVC |
| Отправлено: 19.05.2004, 12:15 |
|
Не зарегистрирован
|
| QUOTE | | что это за зверь такой, псевдо реляционная СУБД |
Под термином псевдо реляционная СУБД я подразумевал системы, в которых вопросами целостности данных и интерприторованием команд SQL занимаетс не сервер БД а клентское приложение. Приношу извинения по поводу случайно пострадавшего Paradox'а. Мне надо было сказать SQL'евские СУБД. |
|
| nisan |
| Отправлено: 20.05.2004, 05:20 |
|
Не зарегистрирован
|
| QUOTE (Gedeon @ 19/05/2004, 12:46) | | Все-таки давайте определимся какая БД. Если это сервер, то что значит в среднем? Если сервер, то перекладывайте всю работу на него, и будет быстро, независимо от клиентов. |
В среднем это типа там есть машинки и слабее и мошнее, но не намного.
Я и хочу делать InterBase, сначала это будет работать на слабеньких машинах, а потом появить сервак, но чтобы он появился надо сделать программу. |
|
| olegenty |
| Отправлено: 20.05.2004, 06:48 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
приведи список параметров по постам, и нарисую я тебе эту базу в Interbase
|
|
