MySQL общая таблица для разных типов

Question

MySQL общая таблица для разных типов

0

Я хотел бы создать общую таблицу в mysql (например, repair) для двух разных таблиц (например, sportscar и tank). Оба должны быть отремонтированы, и здесь возникает моя проблема. У меня не может быть только id (PK) двух столов sportscar и tank в repair стола, потому что я не могу выбрать для ID 1, если он из sportscar или из tank. Поэтому я добавил type_id также в repair таблицы. Так что vehicle_id = 1 и type_id = 2 должны определить, что это из tank, а идентификатор транспортного средства - 1. До сих пор так хорошо, но, к сожалению, он не работает. Я понятия не имею, почему, но это, кажется, не принимать как - то vehicle_id и type_id в качестве составного ключа. В SqlYog мне не разрешено выбирать соответствующую запись, потому что она всегда пуста в связанных таблицах. Я пробовал много разных комбинаций, даже чтобы установить id и type_id как составной PK в таблицы sportscar и tank, но не работал. Что я делаю неправильно? Не могли бы вы указать мне правильное направление? Спасибо.

user2511599 25 июль 2018, в 13:49

Источник

0

Ремонтный стол должен иметь FK от CAR, а не специализированные столы. И у специализированных таблиц также должен быть FK к CAR, так как отношение 1 к 1 от автомобиля к специализированному, автомобильный реестр также является специализированным. Вы можете сохранить таблицу типов, хотя в этом нет необходимости.
Jorge Campos 25 июль 2018, в 11:54
0

car (id, type_id, someAttr); sportscar (id_fk_toCar, otherAttr); hothatch (id_fk_toCar, otherAttr); repair( id, id_fk_to_car, otherAttr)
Jorge Campos 25 июль 2018, в 11:56
0

Нет, специализированные таблицы будут хранить только специализированные атрибуты, думайте об этом, как о всех атрибутах из спортивных автомобилей, которые находятся в автомобильном столе, и вы заполняете только те, которые есть у автомобиля. И чтобы запросить его, вы просто сделаете левое соединение на оба автомобиля. id_fk_to_car в обоих специализированных также должен быть PK в обеих таблицах.
Jorge Campos 25 июль 2018, в 12:06
0

Если вы воспользуетесь моим предложением, то сам автомобиль уже является специализированным. Таким образом, чтобы получить данные, вы присоединяетесь к ремонту с автомобилем и оставляете соединение со спортивным автомобилем и с помощью hothatch, таблица с идентификатором, отличным от NULL, является вашим типом (вот почему вам не нужен тип)
Jorge Campos 25 июль 2018, в 12:08
0

Единственный способ сделать это (так как вы удалили родительскую таблицу, например, машину), это добавить два исправляемых поля с ограничениями для обеих таблиц. Тогда вы будете контролировать его через sql. Что действительно плохой дизайн. Вам следует придерживаться модели наследования, которая гораздо более масштабируема, чем та, которую вы хотите использовать любой ценой.
Jorge Campos 25 июль 2018, в 14:12
0

И просто невозможно добавить внешний ключ для двух разных таблиц в одной таблице для одного и того же столбца. Это не разрешено ни в SQL Ansi, ни в любой базе данных на рынке, поддерживающей ограничения FK.
Jorge Campos 25 июль 2018, в 14:22
0

Просто чтобы показать, как плохо иметь FK для каждого стола в ремонте. Сегодня у вас есть два типа, представьте себе, если вы добавите в свою модель еще 30 типов транспортных средств, вам придется добавить еще 30 FK для ремонта, можете ли вы представить себе головную боль для этого?
Jorge Campos 25 июль 2018, в 14:24
0

Зачем мне добавлять еще 30 ФК? Простой составной ключ из двух ключей должен определять все возможности, не так ли? Это только новый идентификатор типа, что такое evtl. новый.
user2511599 25 июль 2018, в 14:26
0

Нет, потому что вы не можете ответить на этот вопрос: составить, с каким ключом и из какой таблицы? например, repair (id, fk_tank? | fk_sport? ) это просто невозможно в sql.
Jorge Campos 25 июль 2018, в 14:28
0

type_id = 1 = спортивный автомобиль, type_id = 2 = бак, так что я знаю, какая таблица.
user2511599 25 июль 2018, в 14:31
0

хорошо, у вас есть ремонт и тип для какого автомобиля?
Jorge Campos 25 июль 2018, в 14:32
0

Вот что я говорю: чините (id = 1, typ = 1) у вас есть ремонт для спортивного автомобиля, но вы не знаете, для какого спорткара, чтобы узнать его, вам нужно починить (id = 1, typ = 1, sportid = 1) это нормально, но теперь вы не можете иметь за этим столом танк, который можно было бы иметь в вашей модели : ремонт (id = 1, typ = 1, sportid = 1, tankid = null) до спортивный автомобиль или ремонт (id = 1, typ = 2, sportid = null, tankid = 1) для танка. Теперь понятно?
Jorge Campos 25 июль 2018, в 14:52
0

нет тебе не нужен танкид. У вас есть ремонт (id, vehtype_id = 2, veh_id = 1) =>, поэтому я знаю, что это из таблицы tank, и идентификатор равен 1. Это может быть vehtype_id = 1, veh_id = 1 =>, поэтому я знаю, что это идентификатор 1 из Sportscar , Если у меня есть новый тип, я могу просто добавить его в таблицу vehtype и создать новую таблицу, например самолет (type_id = 3), теперь в ремонте это может быть (id, vehtype_id = 3, veh_id = 1), поэтому id 1 с самолета. Я так думаю, тебе не нужен общий стол. Но это не имеет большого значения, потому что, как вы говорите , просто невозможно добавить внешний ключ для двух разных таблиц в одной таблице для одного столбца.
user2511599 26 июль 2018, в 05:35
0

Однако я думал, что составной ключ должен позволять это делать. Почему? Из-за vehtype_id => всегда понятно, на какую таблицу вы ссылаетесь.
user2511599 26 июль 2018, в 05:40
0

Я не позволил бы преуменьшать любые вопросы, потому что это просто глупо. Что мы можем достичь с этим? Если кто-то что-то ищет, он / она хочет стать лучшим человеком с большим количеством знаний. Теперь с понижением мы говорим: ты глуп, иди домой и оставайся таким навсегда. Если нет возможности понизить голос, худшее, что может случиться, это то, что вы не получите никакого ответа, и это будет гораздо более человечным. Вы можете подумать, что, возможно, ваш подход не совсем в порядке, и вы можете подумать об этом, как я могу лучше спросить, или как я могу сначала лучше понять, в чем заключается моя проблема.
user2511599 26 июль 2018, в 05:47
0

Я думаю, что эта тема описывает в точности то же самое: dba.stackexchange.com/questions/30115/… upvotes 4x, так что это глупый вопрос или нет? Иногда вы не можете точно определить свою проблему, и вы не можете найти правильный ответ, но теперь я знаю больше, и я могу лучше искать и вуаля, я не единственный, кто хочет знать то же самое. В любом случае, я бы предложил mysql (oracle) разрешить ссылку на несколько таблиц в случае составного FK. :)
user2511599 26 июль 2018, в 06:02
0

Я не понизил ваш вопрос. У вас нет возможности узнать, кто был, так что не обижайте людей, не зная наверняка (например, downvoter оставляет комментарий, тогда вы знаете). Я был просто выключен. Итак, читая ваши комментарии, вы, кажется, поглощены своими собственными моделями. В настоящее время автомобиль является ТИПОМ, поэтому вы можете иметь только одну комбинацию ремонта для каждого типа, который вы до сих пор не знаете, какой (спортивный или танковый) получил ремонт. И ссылка, которую вы предоставили, точно описывает то, чему я пытаюсь научить вас с самого начала. Множественное наследование и точность со специализированными ключами как первичными в других.
Jorge Campos 26 июль 2018, в 23:17
0

таблица ... присмотрись к сценарию. «В любом случае, я бы предложил mysql (oracle) разрешить ссылку на несколько таблиц в случае составного FK», это просто невозможно по ряду причин.
Jorge Campos 26 июль 2018, в 23:18
0

Извините, я не имел в виду, что вы проголосовали против, я адресовал свой комментарий тому, кто имеет (я знаю, мы не можем знать, кем он был).
user2511599 27 июль 2018, в 05:42
0

Конечно, я не понимаю, как мне это сделать, если бы я знал, что меня здесь нет. Вы можете поправиться, только если попытаетесь нарушить свои границы и ступить на землю, которую вы не знаете (пока). В любом случае, большое спасибо за ваши комментарии, теперь я понимаю, в чем смысл. Поскольку уже есть много подобных вопросов, я бы просто удалил их, если это нормально для вас.
user2511599 27 июль 2018, в 06:53
0

Нет необходимости удалять. Это обсуждение также ценно для любого, кто его видит, поскольку на нем есть хорошие изображения. Будь как будет. Вы можете принять ответ от @Zack, так как он сказал то же самое, что и я, а также дал хорошую ссылку для обсуждения. Ура,
Jorge Campos 27 июль 2018, в 12:15

Показать ещё 19 комментариев

Теги:

mysql

sql

composite-key

1 ответ

Ещё вопросы

Ремонтный стол должен иметь FK от CAR, а не специализированные столы. И у специализированных таблиц также должен быть FK к CAR, так как отношение 1 к 1 от автомобиля к специализированному, автомобильный реестр также является специализированным. Вы можете сохранить таблицу типов, хотя в этом нет необходимости.
car (id, type_id, someAttr); sportscar (id_fk_toCar, otherAttr); hothatch (id_fk_toCar, otherAttr); repair( id, id_fk_to_car, otherAttr)
Нет, специализированные таблицы будут хранить только специализированные атрибуты, думайте об этом, как о всех атрибутах из спортивных автомобилей, которые находятся в автомобильном столе, и вы заполняете только те, которые есть у автомобиля. И чтобы запросить его, вы просто сделаете левое соединение на оба автомобиля. id_fk_to_car в обоих специализированных также должен быть PK в обеих таблицах.
Если вы воспользуетесь моим предложением, то сам автомобиль уже является специализированным. Таким образом, чтобы получить данные, вы присоединяетесь к ремонту с автомобилем и оставляете соединение со спортивным автомобилем и с помощью hothatch, таблица с идентификатором, отличным от NULL, является вашим типом (вот почему вам не нужен тип)
Единственный способ сделать это (так как вы удалили родительскую таблицу, например, машину), это добавить два исправляемых поля с ограничениями для обеих таблиц. Тогда вы будете контролировать его через sql. Что действительно плохой дизайн. Вам следует придерживаться модели наследования, которая гораздо более масштабируема, чем та, которую вы хотите использовать любой ценой.
И просто невозможно добавить внешний ключ для двух разных таблиц в одной таблице для одного и того же столбца. Это не разрешено ни в SQL Ansi, ни в любой базе данных на рынке, поддерживающей ограничения FK.
Просто чтобы показать, как плохо иметь FK для каждого стола в ремонте. Сегодня у вас есть два типа, представьте себе, если вы добавите в свою модель еще 30 типов транспортных средств, вам придется добавить еще 30 FK для ремонта, можете ли вы представить себе головную боль для этого?
Зачем мне добавлять еще 30 ФК? Простой составной ключ из двух ключей должен определять все возможности, не так ли? Это только новый идентификатор типа, что такое evtl. новый.
Нет, потому что вы не можете ответить на этот вопрос: составить, с каким ключом и из какой таблицы? например, repair (id, fk_tank? | fk_sport? ) это просто невозможно в sql.
type_id = 1 = спортивный автомобиль, type_id = 2 = бак, так что я знаю, какая таблица.
хорошо, у вас есть ремонт и тип для какого автомобиля?
Вот что я говорю: чините (id = 1, typ = 1) у вас есть ремонт для спортивного автомобиля, но вы не знаете, для какого спорткара, чтобы узнать его, вам нужно починить (id = 1, typ = 1, sportid = 1) это нормально, но теперь вы не можете иметь за этим столом танк, который можно было бы иметь в вашей модели : ремонт (id = 1, typ = 1, sportid = 1, tankid = null) до спортивный автомобиль или ремонт (id = 1, typ = 2, sportid = null, tankid = 1) для танка. Теперь понятно?
нет тебе не нужен танкид. У вас есть ремонт (id, vehtype_id = 2, veh_id = 1) =>, поэтому я знаю, что это из таблицы tank, и идентификатор равен 1. Это может быть vehtype_id = 1, veh_id = 1 =>, поэтому я знаю, что это идентификатор 1 из Sportscar , Если у меня есть новый тип, я могу просто добавить его в таблицу vehtype и создать новую таблицу, например самолет (type_id = 3), теперь в ремонте это может быть (id, vehtype_id = 3, veh_id = 1), поэтому id 1 с самолета. Я так думаю, тебе не нужен общий стол. Но это не имеет большого значения, потому что, как вы говорите , просто невозможно добавить внешний ключ для двух разных таблиц в одной таблице для одного столбца.
Однако я думал, что составной ключ должен позволять это делать. Почему? Из-за vehtype_id => всегда понятно, на какую таблицу вы ссылаетесь.
Я не позволил бы преуменьшать любые вопросы, потому что это просто глупо. Что мы можем достичь с этим? Если кто-то что-то ищет, он / она хочет стать лучшим человеком с большим количеством знаний. Теперь с понижением мы говорим: ты глуп, иди домой и оставайся таким навсегда. Если нет возможности понизить голос, худшее, что может случиться, это то, что вы не получите никакого ответа, и это будет гораздо более человечным. Вы можете подумать, что, возможно, ваш подход не совсем в порядке, и вы можете подумать об этом, как я могу лучше спросить, или как я могу сначала лучше понять, в чем заключается моя проблема.
Я думаю, что эта тема описывает в точности то же самое: dba.stackexchange.com/questions/30115/… upvotes 4x, так что это глупый вопрос или нет? Иногда вы не можете точно определить свою проблему, и вы не можете найти правильный ответ, но теперь я знаю больше, и я могу лучше искать и вуаля, я не единственный, кто хочет знать то же самое. В любом случае, я бы предложил mysql (oracle) разрешить ссылку на несколько таблиц в случае составного FK. :)
Я не понизил ваш вопрос. У вас нет возможности узнать, кто был, так что не обижайте людей, не зная наверняка (например, downvoter оставляет комментарий, тогда вы знаете). Я был просто выключен. Итак, читая ваши комментарии, вы, кажется, поглощены своими собственными моделями. В настоящее время автомобиль является ТИПОМ, поэтому вы можете иметь только одну комбинацию ремонта для каждого типа, который вы до сих пор не знаете, какой (спортивный или танковый) получил ремонт. И ссылка, которую вы предоставили, точно описывает то, чему я пытаюсь научить вас с самого начала. Множественное наследование и точность со специализированными ключами как первичными в других.
таблица ... присмотрись к сценарию. «В любом случае, я бы предложил mysql (oracle) разрешить ссылку на несколько таблиц в случае составного FK», это просто невозможно по ряду причин.
Извините, я не имел в виду, что вы проголосовали против, я адресовал свой комментарий тому, кто имеет (я знаю, мы не можем знать, кем он был).
Конечно, я не понимаю, как мне это сделать, если бы я знал, что меня здесь нет. Вы можете поправиться, только если попытаетесь нарушить свои границы и ступить на землю, которую вы не знаете (пока). В любом случае, большое спасибо за ваши комментарии, теперь я понимаю, в чем смысл. Поскольку уже есть много подобных вопросов, я бы просто удалил их, если это нормально для вас.
Нет необходимости удалять. Это обсуждение также ценно для любого, кто его видит, поскольку на нем есть хорошие изображения. Будь как будет. Вы можете принять ответ от @Zack, так как он сказал то же самое, что и я, а также дал хорошую ссылку для обсуждения. Ура,

Zack · Accepted Answer · 2018-07-25T12-38-00.000Z

Как сказал @Jorge, ваша таблица Repairs должна быть привязана к базовому Cars (или Vehicles средству), в котором хранятся как спортивные автомобили, так и танки. Что-то вроде Vehicles(vehicle_id, vehicle_type, other_atts).

В зависимости от того, какую информацию вы храните в баках и спортивных автомобилях, вы можете при необходимости создавать специализированные таблицы. Представление наследования в SQL является сложной темой, но может быть сделано несколькими способами. Например, см. Как вы можете представить наследование в базе данных? ,

так что мне нужна главная общая базовая таблица в любом случае, верно? Наследование таблиц классов (или Table Inheritance) - вот что мне нужно. Выглядит неплохо. Я думаю, что я получил картину сейчас. Вот почему @jorgecampos сказал, что будут отношения 1: 1?
Да, именно так. PK в обеих специализированных таблицах также является FK для родительской таблицы, что делает соотношение 1: 1.
Да, но это зависит от того, какую информацию вы храните о танках и спортивных автомобилях. Вы также можете иметь таблицу VehicleAttributes , в которой можно перечислить несколько атрибутов для одного транспортного средства.
Спасибо за ваш комментарий. Поскольку уже есть много подобных вопросов, я бы просто удалил их, если это нормально для вас.