Люди дайте совет как организовать:
есть база приема приборов в ремонт (писал не я:()
принимают от физ. лиц и от дилеров
грубо говоря ведутся паралельно два комплекта таблиц
Т1 - инфа о клиенте,
Т2 - инфа о приборе,
и такие же для дилера и с десяток справочников,
стоит задача перенести все это на SQL
есть идея объединить обе Т2 в одну таблицу
Т1 не получится объединить, в каждой своя нумерация и они немного отличаются.
Как организовать ключи,
стоит ли объединять?
Сейчас это в аксесе 2000
должно быть на SQL + VB(или BC++), ADO

Всем за ранее спасибо!

проблема в том в каждой Т1 идет нумерация счетчиком (своя и разная),
и существующую инфу нужно перетащить в новую базу :(

>ИМХО самое тривиально - добавить новое поле в Т1 типа счетчик. Добавить >поле
>LongInt в подчиненные таблицы. Заполнить их с помощью update значениями
>счетчика. Потом изменить связи - сделать счетчик внутренним ключом, а в
>подчин. это числовое поле - внешним.

sory, отсутствовал некоторое время:)
я не понял, (не пинайте, я только учусь),
поясните подробней плиз

>"Не понял" к чему конкретно относится?
В Т1 уже есть счетчики.

>Добавить поле
>LongInt в подчиненные таблицы. Заполнить их с помощью update значениями
>счетчика. Потом изменить связи - сделать счетчик внутренним ключом, а в
>подчин. это числовое поле - внешним.

мне хотелось связать две главные с одной подчиненной,
я не знаю возможно ли это :(
может раньше я не так объяснил, прошу прощения!

специалистами не рождаются......

>Я и сам не специалист. Но пытаюсь по мере сил разбираться.
а я только пытаюсь начинать :)

>Насколько я понял, возник вопрос о том, как объединить две таблы в одну.
>Мой ответ был на эту тему. Если есть уже счетчик, то нужно просто добавить
>записи из одной таблицы в другую. А связать одну таблицу с двумя главными
>конечно можно. Насколько я понимаю, их и предложили объединить. ИМХО
>предложение весмьа разумное и стоящее размышлений. Размышления по
>поводу технич. трудности "справлюсь - не справлюсь" не должны быть >аргументом при изменении схемы БД. Чем раньше будут исправлены огрехи
>схемы, тем меньше будут накапливаться проблемы.

К сожалению база написана до меня, (еще меньшим специалистом) :)
вот пытаюсь исправлять огрехи (на сколько могу, т.к. это не основной мой профиль).
Там вообще две таблицы для клиентов и дилеров (большие!!!), включает каждая инфу о приборе, я хочу выделить инфу прибора в отдельную таблицу оставив две для клиентов и дилеров (разная там инфа), так техникам удобнее будет работать и скорость выше.

спасибо за поддержку!

> Схему можно увидеть?
да схемы на данный момент особо нету :(
есть две основные таблицы Клиенты и Дилеры (не связаные) в каждой из которых содержится вся инфа:
о клиенте (ФИО, адрес, и т.д.) + о приборе (марка, модель, зав. номер и т.д.) + дата приема, дата выдычи, статус ремонта, неисправность, стоимость, имя техника, гарантия и подобная.
Таблица Дилеры отличается в части инфы о клиенте (существенно).
В каждой таб. своя нумерация, заполняется в основном из справочников,
каждое подразделение свои поля.
Неудобство в том, что техникам и складу приходится работать с двумя таблицами (тоже отслеживание повторных ремонтов).
Написано это в Акцесе, в каждой таблице уже более 20 т. записей, и по сети уже заметно тормозит и иногда вылетает.
Возникла необходимость перенести это на SQL.
У меня есть мысль раделить эти таблицы на 3, Клиенты, Дилеры и Приборы (общей для обоих) с соответствующе инфой.
Вот и вся схема.
Как привязать справочники пока вопросов нет.
сори за длинное объяснение!

>Т.е. в таблицах Дилеры и Клиенты есть инфа о приборах... Значит, и дилеры и
>клиенты должны в таблице могут быть упомянуты неограниченное кол-во раз?
>Что является ключами таблиц?
Счетчики Номера Заказов в обоих

>На самом деле не так много нужно переделывать. Эта общая таблица уже
> есть (по идее должна называться не Приборы, а Ремонты Приборы - должна
общей нет ее нужно сделать, назвать ее можно как угодно

>быть другая таблица) - надо только из нее выбрать информацию о дилерах и
>клиентах и развести в две таблицы.
Какая будет главной а какая починенной
>Так зачем дело встало? Составить запрос на добавление таблиц?
Наверное в ДНК :)
У меня не получается связать эти таблицы в кучу с нормальной поддержкой целостности данных.
Не хочу организовывать поддержку отношений таблиц в клиентской проге, т.к. всякое может быть (сбои сети, зависания и т.п.)
Но очень может быть, что я что-то недопонимаю :)

>(Проще создать новый мдб файл, и импортировать в него таблицы в
>виде "только структура".
файл приложен, с двумя таблицами

>В "клиентской проге" - fron-end mdb не должно быть таблиц.
так и есть

>А целостность нужно поддерживать грамотными связями и их
>настройками - в back-end mdb.

что я и хочу получить, но тяму пока не хватает:))

>Вы уж извините, но я - пас:
Нет проблем :)
>довольно много чего нужно сделать, а работы и
>так хватает. Может, кто-другой захочет помочь.
я не прошу за меня ни чего делать, мне-бы пинок в нужную сторону :)
спасибо.

>Пинок в нужную сторону: построить подходящую ER схему. Вполне возможно,
Думаю над этим :)
>что имеющаяся схема и отвечает задаче (принципиально). Но скорее всего
>все-таки инфо о ремонтах и клиентах нужно держать в разных таблицах.
>Проблема действительно в том, что кажется неоправданным сводить частных
>лиц и дилеров в одну таблицу. По теории они должны быть в разных
>таблицах, обладая весьма отличающимся набором аттрибутов.
я вэтом уверен :)
>Я попробую еще на досуге подумать.
спасибо!!!

Iskander68См. файл - только в качестве пинка! Кстати, я не профи, поэтому воспринимайте вдвойне критично. Вполне вероятно, что связи там - бред.
Спасибо! буду смотреть, как применить к моей проблеме - что получится раскажу.
У меня знакомый есть, теоретик БД (разрабатывал большие базы давно) попробую на выходных напоить его пивом может что придумаем.:)