Полностью согласен. Интересно было-бы все-таки взглянуть на эту структуру.

Кстати, Chas, ты ведь сам сказал что у тебя "несколько таблиц с примерно одинаковым содержанием" ... Это очень не верно. Информация может повторяться только в очень редких случаях :
1, редунданция для критических запросов (тобиш повторяющаяся информация которая "облегчает" работу базы данных)
2, упрощенная структура (где данные в таблицах не полностью изолированны) что-бы упростить с нею работу.

Вот тебе кусок бекапа - оцени:

create table orders
(
iID int (12) primary key auto_increment,
dtCreationDate date,
iCustomerID int (6),
dPaid double (10,4)
);
create table orders_trains (
iID int (6) primary key auto_increment,
iOrderID int (6),

iCarType int (2),
iDirectionType int (2),
sTrainNumber varchar (6),

dtArrivingDate date,
sArrivingTime varchar (10),
dtDepartureDate date,
sDepartureTime varchar (10),
dPrice double (10,4)
);
create table orders_propositions (
iID int (6) primary key auto_increment,
iOrderID int (6),
iPropositionID int (6),
sService varchar (250),
dPrice double (10,4)
);
create table orders_transfers (
iID int (6) primary key auto_increment,
iOrderID int (6),
sArrivingPlace varchar (100),
iTransportType int (2),
iArriving int (2),
dtArrivingDate date,
sArrivingTime varchar (10),
sArrivingIssue varchar (10),
iDeparture int (2),
dtDepartureDate date,
sDepartureTime varchar (10),
sDepartureIssue varchar (10),
dPrice double (10,4)
);
Поставленная задача - человек делает заказ покупает, скажем путевку, билет на поезд Киев-Симферополь и трансфер из Симферополя в Ялту в пансионат. Сделать - веб-интерфейс, чтобы можно было делать подобные заказы и тут же получать счет по мылу - где все расписано - что-почем-куда. Для этой же базы - веб-интерфейс администратора - чтобы он мог указать статус заказа (оплачен-неолачен-просрочен-аннулирован), распечатать ваучер, статистику, добавить новый пансионат/группу заездов - короче - я уже около 2х месяцев с ней работаю. Правда администраторскую часть я пишу в Access. Соединил ODBC-драйвером с мускулем. Очень удобно в аксессе проэктировать формы, отчеты.

Извини но dPrice точно надо вывести в отдельную таблицу а потом к нему обращаться через чужие ключи в твоих трех таблицах.

Гм... iOrderID нельзя использовать в качестве ключевого поля -один заказ соответсвует нескольким услугам, у каждой из которых своя цена, orders_trains.iID или orders_transfers.iID имеют свою независимую нумерацию... тогда нужно создавать таблицу типа - orders_prices (iPriceID, dPrice), а в каждой из orders_trains, orders_propositions - заменить dPrice на iPriceID - дурдом... по-другому - не вижу как.
Думаю сделать следующее - в orders - добавить поле dPrice и каждый раз при добавлении новой услуги - пересчитывать поле общей стоимости. Мне думается, так будет и мне удобней работать, и отчеты быстрей будут выполняться типа - сколько у нас заказов за этот месяц...

Если начать с концептуальной модели, то ответ звучит просто: наследование. Т.е. создается entity Prices, содержащий поле dPrice, от которого наследуются нужные таблицы.

Разумеется, нужно построить физическую модель. Если мы строим ее по схеме "генерация родителя и потомков с наследованием ключа", то получается тот способ, который ты описал как "заменить dPrice на iPriceID".

При другом варианте генерации PK потомков перетекают в родителя. В этом случае никакого iPriceID не будет, а в таблицк цен будет композиция всех ключевых полей из твоих таблиц.

Что же до дурдома, то на него вполне похож третий -- на самом деле тоже логичный -- вариант: ВСЕ генерится в одну таблицу с композицией всех собственных полей наследников с полем dPricе, доставшимся от папы.

Обращаю внимание: все три схемы логически эквивалентны и в каждой из них dPrice лежит ровно в одной таблице.

Не забудь про блокировки. Этот способ хорош в плане минимизации правок, но потенциально может создать больше всего проблем.

Ё-мое! Неет, столько пива не бывает. Крези, я теперь знаю, почему Вас крези величать)))))))))))))))))) Блин, если бы во всех моих книгах принципы БД были описаны ТАК, я бы до сих пор бесиком баловался.
Я... я прям зауважал старшее поколение )))
ЗЫ. Так. Тред переходит во флуд. Спасибо г-ну Комраду за совет с запросом - попробую еще раз.
ЗЗЫ: Крези, хотелось бы мне на кусок вашей базы глянуть...

ты зря так ... дельное говорит comarada Крэзи

а что до запроса, попробуйте батенька ... главное в where все правильно выставьте ... Один null и будет опять пустое поле

Мне до батеньки еще очень далеко.... во всех смыслах...
Я отлично понял все, что сказал Крези, просто, ЗАЧЕМ говорить таким сложным языком. У меня однажды был препод по БД в универе, который советовал нам книгу 82 года рождения, писал в Delphi 3 и называл таблицу картотекой. Ну... разве в этом профи? ЗАпрос попробую завтра. У меня местное время - 3 часа ночи.

а в библии тоже много че интересного? а когда она написана? в общем я опоздал, это точно. эх. хороший тред получился.

Ты в состоянии сказать это проще без потери смысла?

Называть таблицу картотекой -- неграмотно. Что до книг, то второе издание книги Дейта "Введение в системы баз данных" вышло на русском языке в 1980г. :) Сейчас продается седьмое издание, но от чтения второго пользы будет не сильно меньше. Что любопытно, имеется об этой книге вот такое мнение: "Если книгу 1980 года я смело рекомендовал и продолжаю рекомендовать в качестве учебника для студентов, то уже книгу 1999 года я рекомендую начинающим студентам только с оговорками.". Цитата отсюда.

При чем здесь Delphi 3 -- осталось для меня загадкой... :)