| |
|
|
| | Доброе утро
Подскажите пожалуйста возможно ли добавлять записи в две разные таблицы так чтобы ключевое поле в каждой из них создавалось автоматически (что-то вроде счетчика) а ключевое поле в первой не повторялось во второй. Если это реально, то как это можно реализовать
Заранее спасибо | |
| |
| |
| |
|
|
| | сделать счетчик не последовательным а случайным, или еще лучше код репликации (тогда точно не повторится) | |
| |
| |
| |
|
|
| | это не про физиков-юриков задача, случайно? 
если у тебя есть необходимость в таком счетчике, значит есть сущность которая этим счетчиком идентифицируется
у этой сущности может и не быть иных атрибутов, кроме того, что она есть/нет.
создай еще одну таблицу для хранения такого супер-типа
tblEntries
-------------------------------
EntryID - (autoincrement PK)
------------------------------
EntryExists (boolean)
-------------------------------
в двух других таблицах создай внешний ключ на эту таблицу
tblEntities
---------------------
EntityID (PK)
---------------------
EntryID (FK)
---------------------
EntityName
---------------------
FK в такой(их) таблице(цах) на PK таблицы супертипа и будет сквозным идентификатором
ЗЫ
если я правильно уловил ТЗ | |
| |
| |
| |
|
|
| | Спасибо за оперативность
Создание третьей таблицы для хранения ключевого поля наверняка увеличит вес базы данных потому как остальные таблицы имеют достаточно большое кол-во записей. Этот вариант мне более менее понятен. Для начала попробую разобраться с репликацией может получится что-нибудь более простое.
С уважением ПАСАТ | |
| |
| |
| |
|
|
| | а если создать составной ключ из двух столбцов: один счетчик, другой символьный | |
| |
| |
| |
|
|
| | Если я правильно понял символьный это когда юзер присваивает код самостоятельно. Но мне кажется что в этом случае существует вероятность что рано или поздно составной ключь может все таки совпасть и второе для моей задачи все таки нужно чтобы ключевое поле было только одно.
В принципе мне это нужно для того чтобы создав запрос на объединение этих разных таблиц получить запрос с полем в котором значение для каждой записи ни разу не повторится т.е. будет уникальным
Может существуют какие то другие решения подобной задачи а именно нужно получить запрос в котором будут записи двух объединенных таблиц с полем в котором будет некое уникальное значение для каждой записи | |
| |
| |
| |
|
|
| | так бы сразу и сказал
таблица tab1, ключ id, значение val
таблица tab2, ключ id, значение val
select id & "t1" as metka , val from tab1
union select id & "t2" as metka , val from tab2 | |
| |
| |
| |
 18 Кб. |
|
| | Огромное спасибо за предложенное решение.
Надеюсь что также легко можно решить и другой вопрос.
Имеется три таблицы [Jurid persona]-список юр.лиц, [Fiz persona]-список физ.лиц и [Dokumenti]-список счетов для юр. лиц и физ.лиц.
[Fiz persona]-[Dokumenti]; [Jurid persona]-[Dokumenti] имеют связь один ко многим с сохранением целостности данных (см. пркр. файл).
Создав запрос на объединение таблиц [Fiz persona]-[Jurid persona] и если код юр.лица и физ.лица совпадает то в дальнейшем невозможно определить кому конкретно выписан счет юр.лицу или физ.лицу с кодом 1. Вот если бы ключи у них были уникальные то проблем бы не возникало.
Или нужно как-то по другому структуировать базу. Я например сначала вносил юр.лиц и физ.лиц в одну таблицу, но дело в том что юр.лица имеют много полей, которые не нужны для физ.лиц и наоборот. Сейчас хочу от этого уйти выше описанным способом там ли я ищу, не хочется делать лишних движений. Да и еще нужно исходить из того что таблица [Dokumenti] должна быть одна для всех.
Еще раз большое ВСЕМ спасибо. | |
| |
| |
| |
|
|
| | я бы все же сделал одну таблицу для всех лиц с общими для Юр. и физ. атрибутами
Различные атрибуты разннес бы в разные таблицы.
Или сделал бы СЛУЧАЙНЫЙ счетчик.
или генерил ключ руками. | |
| |
| |
| |
|
|
| | либо вообще сделать общую таблицу со всеми атрибутами и юр. и физ. лиц. Соответственно в каждом случае заполнял необходимые поля | |
| |
| |
| |
|
|
| | 1. Если оставлять одну таблицу (это тоже самое что есть сейчас) в ней имеется много полей, которые для половины записей просто не нужны - это как раз то от чего я хочу отойти.
2. Если различные атрибуты разннести в разные таблицы то тогда уже получается три таблицы это наверное тоже самое что предлагал Explorer (здесь вроде все понятно).
3.Если создать случайный счетчик мне кажется что при этом все-таки остается вероятность что рано или поздно ключи могут совпасть
4. В первом сообщении Вы писали что можно использовать код репликации. Или это не тот случай когда это нужно делать | |
| |
| |
| |
|
|
| |
В первом сообщении Вы писали что можно использовать код репликации. Или это не тот случай когда это нужно делать
|
Поле счетчик в ACCESS может быть:
Длинным целым, а может быть кодом репликации - это не значит что его обязательно надо использовать для репликации, он точно будет уникальным...вот только работать с ним не очень удобно....
Выше предлагался вариант сделать составной ключ по двум полям, первое поле - счетчик, второе константа для данной таблицы. | |
| |
| |
| |
|
|
| | 1) все зависит от того, насколько полные сведения о контрагенте вы храните, если отличия будут в том, что
для Юриков есть ОГРН ОКПО КПП и нет номера паспорта а
для физиков есть номер паспорта пол и возраст, но нет других деталей
то нет нужды париться - лучше действительно сделать одну таблицу - не страшно если часть полей не будет заполнена - это не увеличит значительно физический объем данных
1а) контрагентов не так и много - если их будет пара тысяч - не вопрос
1б) Access достаточно экономно и эффективно хранит данные
1в) в случае чего (развитие проекта) от такой структуры можно легко перейти к структуре 2
2) способ, который я привел в качестве примера - это тот способ. которым я пользуюсь сам, значительных минусов не наблюдал пользоваться достаточно удобно
3) да вероятность останется, хотя ее можно легко разрулить обработав ошибку, впрочем это зависит непосредственно от количества данных в таблицах (вероятность пересечения возрастает с увеличением количества записей в таблицах)
4) ИМХО это совершенно не тот случай для репликации
***********
упс, я размещался в ответ на вопрос автора, Олег, не знаю почему прикрутилось к твоему посту :))) | |
| |
| |
| |
|
|
| | Я сейчас попоробовал на маленьком примере - заменил связанные поля (длинное целое на код репликации) мне кажется что все нормаьно.
Какие возможны неудобства если использовать код репликации а не длинное целое | |
| |
| |
| |
33 Кб. |
|
| | я не использовал такой подход - ничего определенного сказать не могу, ИМХО если не придется каким-либо образом использовать код клиента, то ничего ИМХО, даже занятно...
в приложении коротенькая схемка с супертипом
в таблице Entities поля одинаковые - "сквозные"
AddressID - Юр.адрес компании или адрес прописки часного лица
TaxCode - ИНН Юр.Лица или Частного лица
Остальные данные "не пересекающиеся" разнесены в разные таблицы и могут быть "слиты" вместе в запросах | |
| |
| |
| |
|
|
| | Благодарю за всесторонее освещение данного вопроса  | |
| |
| |
