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

← →
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 или думать дальше.

[12] by © (22.09.04 15:58)

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

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

[14] by © (22.09.04 16:14)

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

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

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

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

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