Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2004.10.10;
Скачать: CL | DM;

Вниз

Можно ли ориентироваться на постоянные данные?   Найти похожие ветки 

 
by ©   (2004-09-22 14:57) [0]

Есть несколько таблиц, в которых хранится информация, упрощенно это ID NAME. В этих таблицах может быть как информация используемая программой (с определенными ID), так и данные введенные пользователем.
Как лучше поступить в этой ситуации:
1) зарезервировать диапазон ID для системных данных
2) сделать дубликаты таблиц, т.е. две таблицы с одинаковой структурой
3) в таблице ввести признак системной запись

что посоветуете?


 
clickmaker ©   (2004-09-22 15:07) [1]

Если системные данные не будут пополняться, то можно 1)
Но грамотнее наверно 3)


 
by ©   (2004-09-22 15:12) [2]

Системные данные будут изменятся и пополнятся, причем на их ID будут завязаны другие таблицы. Если просто поставить признак, то возникает вопрос как обновлять базы в разных местах. Ведь если у разработчика а БД ID 777 соответствует како-то записи, то у клиента этот ID может быть уже занят введенной им записью. Вот и проблема, с которой столкнулся.


 
by ©   (2004-09-22 15:15) [3]

Самое простое по чати обновлений - это дублирующая структура, но таких таблиц несколько, на них завязаны процедуры и пр. Т.е. данные обновлять просто, но поддерживать структуру трудно.


 
Anatoly Podgoretsky ©   (2004-09-22 15:15) [4]

Кто вводит системные данные, вот отсюда и пляши. И еще это разные сущности или одна.


 
by ©   (2004-09-22 15:29) [5]

Системные данные вводит разработчик, это описание метаданных системы. Остальные данные вводят пользователи (точнее разработчики заказчика) и они являют собой метаданные конкретного АРМ. Сущность фактически одна, так как на основе системных данных и данных пользователя генерируются соответствующие формы.
Просто нужен способ синхронизации данных таблиц БД разработчика и БД заказчика. Полей там естественно много больше чем просто одно поле Name.


 
Skyle ©   (2004-09-22 15:30) [6]

Использовать GUID (uniqueidentifier) и забыть про Id как метод идентификации.


 
Anatoly Podgoretsky ©   (2004-09-22 15:32) [7]

by ©   (22.09.04 15:29) [5]
Или две таблицы или [6]


 
Sandman25 ©   (2004-09-22 15:33) [8]

Можно ввести уникальность Name и искать по нему, при этом необходимо иметь признак "сиcтемности", чтобы нельзя было изменить/удалить системные настройки.


 
by ©   (2004-09-22 15:35) [9]

База у меня Firebird, у неё стандарных средств для генерации GUID вроде нет. Но его можно и с клиента генерировать. А производительность не упадет? Ведь Int наверное лучше индексируется.


 
by ©   (2004-09-22 15:43) [10]

Sandman25 ©   (22.09.04 15:33)
Anatoly Podgoretsky ©   (22.09.04 15:32)

Таблиц которые хранят информацию которую нужно синхронизировать сейчас 5, и полей в них много. Дублирующая структура очень некрасива. Видать прийдется использовать GUID.
Но тоже это не очень хорошо, ведь получается, что для части таблиц БД используется ID GUID, а для остальной ID - Integer


 
Sandman25 ©   (2004-09-22 15:47) [11]

[10] by ©   (22.09.04 15:43)

Попробуйте добавлять ситемные записи с другой стороны диапазона. То есть -1, -2.. для знаковых либо $FFF..FF, $FFF..E... для беззнаковых id.


 
by ©   (2004-09-22 15:58) [12]

Sandman25 ©   (22.09.04 15:47)
Такие данные генератор не сгенерирует. Только на клиенте. Прийдется действительно рассматривать вариант GUID или думать дальше.


 
Sandman25 ©   (2004-09-22 16:08) [13]

[12] by ©   (22.09.04 15:58)

Не понял. Генератор всегда подставляет значения перед вставкой?
Если нет, то можно жестко написать insert into tab(id, ...) values(-1, ...)


 
by ©   (2004-09-22 16:14) [14]

Sandman25 ©   (22.09.04 16:08)
Генератор использется всегда как способ генерации нового ID. Подставить жестко можно, но тогда мы перебираем на себя задачу обеспечения уникальности этого ID.


 
Sandman25 ©   (2004-09-22 16:17) [15]

[14] by ©   (22.09.04 16:14)

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


 
by ©   (2004-09-22 16:22) [16]

Sandman25 ©   (22.09.04 16:17)
Пользователь получает патч и вливает его в БД.
Ну если не принимать во внимание то что ручные insert не очень удобны основному разработчику, то это нормально. Тем более что системные данные это не справочники, а именно метаданные, так что их изменение это достаточно редкий и серьёзный шаг, можно и ручками.
Будем экспериментировать, как-то int со знаком ближе чем GUID )))


 
Sandman25 ©   (2004-09-22 16:27) [17]

Ну если не принимать во внимание то что ручные insert не очень удобны основному разработчику, то это нормально

Никто не мешает использовать и другие способы. Например
load from "data.dat" insert into tab(id, name, ...).
А в data.dat данные слиты через save to "data.dat" select id, name,... from tab на машине разработчика.
Но это уже зависит от СУБД, конечно.



Страницы: 1 вся ветка

Текущий архив: 2004.10.10;
Скачать: CL | DM;

Наверх




Память: 0.51 MB
Время: 0.046 c
14-1095594379
_iceman_home
2004-09-19 15:46
2004.10.10
Проблемы с монитором


14-1095925098
begin...end
2004-09-23 11:38
2004.10.10
NTFS


9-1086801828
Igoryok
2004-06-09 21:23
2004.10.10
Продолжение про Delphi X и концепцию дальнейшего развития


14-1095795066
Opilki_Inside
2004-09-21 23:31
2004.10.10
Кто-нибудь сталкивался с Qt-library?


14-1095784428
Sergey_Masloff
2004-09-21 20:33
2004.10.10
Передать FIBDatabase в COM-dll