|
|
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
Давайте смоделируем ситуацию. Вы - оператор, я - заказчик и по совместительству Ваш сосед-друг. Поехал я в Германию, нашел автомобиль (цена-качество), но не уверен, что авто подойдет по классу выбросов (я не знаю какой класс ЕВРО 2, 3, 4, 5). В нашей стране действует регламент - завозить авто можно только авто классом ЕВРО не ниже 5. Звонить Вам дорого, смс - дешевле. Пишу Вам смс с информацией, которую вижу на авто ВИН (17 символов), дата выпуска, и коммерческое название. Капот закрыт и табличку с типом, вариантом и версией я не вижу. Прошу Вас помочь мне (баня с меня или бутылка). Вы по своей базе пробили, что согласно вин это производитель ВАСЯ, согласно коммерческого названия и производителя выбрали всевозможные ТИПЫ 1. и все предложенные варианты и версии оборудованы двигателями ЕВРО 5. 2. нужно обязательно поднять капот (машина стоит на стоянке в Германии, хозяин живет в Италии), поскольку в варианте ККЕНВЛК стоят двигателя ЕВРО 4. Друг уже думает, ждать ему хозяина или нет. 3. все авто оснащены двигателями ЕВРО 4. Я утрировал ситуацию, но думаю принцип понятен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 13:03 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
rikitikis_ustinovrikitiki, Вот зачем здесь: "Таблица КТС - это и есть главная таблица, куда оператор должен выбрать все хар-ки. Отличительные хар-ки это ВИН, цвет и дата выпуска , остальное нужно взять из таблиц, которые описаны выше или если нет, добавить эти характеристики вручную." указывать производителя, тип, название и т.д.? Как Вы предлагаете связать конкретный ВИН с остальными характеристиками? Я это сделал с помощью ключей: idПроизводитель, idТип, idВар_Вер, idкоммерческое название Я писал - название производителя может меняться (выше пример с Мерседесом) У некоторых производителей нет вариантов и версий (мелкосерийное производство) один тип и все, без деления. У разных производителей кодирование типа может совпадать (поэтому главный идентифицирующий атрибут в таблице ТИП это номер одобрения типа Пример: e1*2001/116*0254*23, если в ТИПе хар-ки поменялись не существенно и обозначение типа остается "старым" и через 5 лет производитель захочет и дальше выпускать этот ТИП номер будет e1*2001/116*0254* 24 ) е1 - страна, которая выдала одобрение, 2001/116 - европейская директива, 0254 - идентификационный номер типа, 23 - порядковый номер изменений. Что Вы предлагаете оставить в таблице ТС? ID первичного ключа таблицы ТС, VIN и FK таблицы КТС. Ну и еще ряд вспомогательных полей, но никаких дополнительных внешних ключей быть там не должно (из представленных на рисунке). rikitikis_ustinovИ что значит "если нет, добавить эти характеристики вручную"? Вы представляете, что о вас скажет человек, которому придется анализировать эту "информацию", если в таблице будет тип или коммерческое название, введенные вручную? Если в справочниках нет нужного типа - надо создать новую запись в справочнике, а не плодить мусор. Другое дело, что могут быть ошибки в документах - название в "техпаспорте" не совпадает с названием, которое использует производитель. И вот для таких случаев надо предусмотреть отдельные поля. Пардон за мой французский, это и значит "создать новую запись в справочнике" ?????????????? Если одно сообщение от автора " r ikitiki", а другое сообщение от автора " R ikitiki" - это ведь не значит, что сообщения написали два разных человека. Поверьте, ламер - это самое мягкое, что потом говорят о "проектировщиках" таких БД люди, которым приходится это всё анализировать. Не надо так делать и портить себе карму. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 13:10 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
rikitikiДавайте смоделируем ситуацию. Вы - оператор, я - заказчик и по совместительству Ваш сосед-друг. Поехал я в Германию, нашел автомобиль (цена-качество), но не уверен, что авто подойдет по классу выбросов (я не знаю какой класс ЕВРО 2, 3, 4, 5). В нашей стране действует регламент - завозить авто можно только авто классом ЕВРО не ниже 5. Звонить Вам дорого, смс - дешевле. Пишу Вам смс с информацией, которую вижу на авто ВИН (17 символов), дата выпуска, и коммерческое название. Капот закрыт и табличку с типом, вариантом и версией я не вижу. Прошу Вас помочь мне (баня с меня или бутылка). Вы по своей базе пробили, что согласно вин это производитель ВАСЯ, согласно коммерческого названия и производителя выбрали всевозможные ТИПЫ 1. и все предложенные варианты и версии оборудованы двигателями ЕВРО 5. 2. нужно обязательно поднять капот (машина стоит на стоянке в Германии, хозяин живет в Италии), поскольку в варианте ККЕНВЛК стоят двигателя ЕВРО 4. Друг уже думает, ждать ему хозяина или нет. 3. все авто оснащены двигателями ЕВРО 4. Я утрировал ситуацию, но думаю принцип понятен. Этот пример еще раз показывает, почему надо использовать искусственные ключи - меньше мусора в голове. Вы вбиваете в обычные текстовые поля "смс с информацией, которую вижу на авто ВИН (17 символов), дата выпуска, и коммерческое название". Потом с помощью различных действий (в том числе различных запросов к базе) пытаетесь найти нужную вам информацию. Но вы на основании данных от пользователя не указываете FK к куче разных таблиц - пользователь может ошибиться. И надо разграничить эти данные - то, что сообщил пользователь, от того, какие связи (данные) должны быть исходя из логики БД. Грубо говоря, если один производитель купил другого производителя год назад, а машина сделана два года назад, и надписи на ней соответствующие, и пользователь эти надписи и переслал в СМС - надо в базе хранить ссылку не на того производителя, которого прислал пользователь, а на правильного с точки зрения данных (того, кто купил). А для надписи на машине предусмотреть отдельное поле. Ну или доработать схему БД, чтобы нормально учитывала подобные ситуации. Например, хранить даты "актуальности" производителя и предусмотреть ссылку на другого производителя для ситуаций покупки / объединения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 13:31 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
s_ustinovID первичного ключа таблицы ТС, VIN и FK таблицы КТС. Ну и еще ряд вспомогательных полей, но никаких дополнительных внешних ключей быть там не должно (из представленных на рисунке). Вы имели в ввиду ID первичного ключа таблицы ТС, VIN и FK таблицы базовая комплектация КТС Если это так, я с Вами согласен Если все таки FK таблицы КТС, тогда не понял ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 13:34 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
rikitikiВы имели в ввиду ID первичного ключа таблицы ТС, VIN и FK таблицы базовая комплектация КТС Да. И лучше уж назвать таблицу не базовая комплектация, а "Вид КТС". Базовая комплектация - это немного другое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 13:37 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
s_ustinovГрубо говоря, если один производитель купил другого производителя год назад, а машина сделана два года назад, и надписи на ней соответствующие, и пользователь эти надписи и переслал в СМС - надо в базе хранить ссылку не на того производителя, которого прислал пользователь, а на правильного с точки зрения данных (того, кто купил). А для надписи на машине предусмотреть отдельное поле. Ну или доработать схему БД, чтобы нормально учитывала подобные ситуации. Например, хранить даты "актуальности" производителя и предусмотреть ссылку на другого производителя для ситуаций покупки / объединения. Вот здесь Вы заблуждаетесь, мне нужны данные на момент производства, а не на сегодня. Если рассуждать согласно Вашей логике, то Ауди А6 2000 года идентична А6 2017 года, и по логике ржавчины еще не должно быть, поскольку 2017 год на дворе. Надписи на машине - это и есть марка и коммерческое название ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 13:45 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
rikitikis_ustinovГрубо говоря, если один производитель купил другого производителя год назад, а машина сделана два года назад, и надписи на ней соответствующие, и пользователь эти надписи и переслал в СМС - надо в базе хранить ссылку не на того производителя, которого прислал пользователь, а на правильного с точки зрения данных (того, кто купил). А для надписи на машине предусмотреть отдельное поле. Ну или доработать схему БД, чтобы нормально учитывала подобные ситуации. Например, хранить даты "актуальности" производителя и предусмотреть ссылку на другого производителя для ситуаций покупки / объединения. Вот здесь Вы заблуждаетесь, мне нужны данные на момент производства, а не на сегодня. Если рассуждать согласно Вашей логике, то Ауди А6 2000 года идентична А6 2017 года, и по логике ржавчины еще не должно быть, поскольку 2017 год на дворе. Надписи на машине - это и есть марка и коммерческое название Ок, приведу другой пример. Например, чоткий любитель антикрыльев на ладах купил себе китайца, и наклеил шильдики от мерседеса. Ну а пользователь это всё и прислал (пользователь может вообще не разбираться в машинах, и просто описал всё, что увидел). Что оператор будет заносить в базу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 13:57 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
s_ustinov, ВИН вспоминаем аксиому (ВИН всегда известен) - согласно ВИН - это китаец, а потом уже шилдики Поэтому был вопрос выше, по поводу маски ВИНа - WAU???4F?????????? -где можно точно определить ТИП ТС, для каждого ТИПа, своя маска Также 10 символ ВИН (90%) модельный год ТС, у ТС есть разница между модельным годом и годом выпуска, модельный год начинается с июля по июнь месяцы, а год выпуска с января по декабрь, если у Вас автомобиль выпущен 05.09.2015, то год выпуска - 2015, а модельный год - 2016 Если не знаем точную дату производства, проверяем максимум 2 года ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 14:13 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
Вспомнил еще один вопрос. Некоторые производители указывают пределы, например: длина мин 2026 макс 2043 например кузов лонг и просто седан на табличке ТС буде стоять длина 2032мм. Мне "2032" заносить в таблицу КТС или создавать новую запись в справочнике (отличие только массы и длины), где мин будет 2032 и мах будет 2032? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 14:27 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
rikitikis_ustinov, ВИН вспоминаем аксиому (ВИН всегда известен) - согласно ВИН - это китаец, а потом уже шилдики Поэтому был вопрос выше, по поводу маски ВИНа - WAU???4F?????????? -где можно точно определить ТИП ТС, для каждого ТИПа, своя маска Также 10 символ ВИН (90%) модельный год ТС, у ТС есть разница между модельным годом и годом выпуска, модельный год начинается с июля по июнь месяцы, а год выпуска с января по декабрь, если у Вас автомобиль выпущен 05.09.2015, то год выпуска - 2015, а модельный год - 2016 Если не знаем точную дату производства, проверяем максимум 2 года На вашем месте я бы в табличке вид тс (или базовая комплектация) хранил бы маску вина, которая позволяет приписать конкретное ТС к определенному виду. В таблице КТС просто записывал бы вин в текстовое поле фиксированной длины. И после создания новой записи КТС и ввода вина на уровне приложения пробовал бы поискать по маске (логика поиска может быть сложной, так как структура вина неоднородная). Нашли один вид - его и предложили пользователю. Нашли несколько видов - предлагаем оператору несколько и заодно отправляем сообщение администратору БД, что есть вин, совпадающий с несколькими масками (вероятно, неправильно маски заданы). Не нашли ничего - предлагаем оператору проверить вин (возможно, он с ошибками) и ручками выбрать производителя и т.д. для выбора вида ТС. Если вообще нужного вида ТС нет - добавляется новый вид (марка, производитель и т.п.) в справочник. После выбора пользователем вида ТС система показывает оператору, что будет записано в КТС - производитель, марка, вид и т.д. - на основании FK таблицы базовая комплектация КТС и связанных таблиц (запрос по нескольким таблицам или вьюшка). Оператор сравнивает с "техпаспортом", и если что-то не совпадает - корректирует соответствующее поле. И это поле не FK, а именно текстовое поле. Ну и администратор БД время от времени проверяет все расхождения - то ли ошибка в справочнике (неправильно написана марка, производитель и т.п.), то ли ошибка в конкретном "техпаспорте". В результате и данные правильные, и можно печатать документы с ошибкой в названии модели, повторяя ошибку из техпаспорта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 14:59 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
Топик уже стал ниачомъ. Раз ТС убежден, что ВИН это отличный первичный ключ - пусть делает на здоровье. Только непонятно, зачем он пришел за советами... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 15:05 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
rikitikiВспомнил еще один вопрос. Некоторые производители указывают пределы, например: длина мин 2026 макс 2043 например кузов лонг и просто седан на табличке ТС буде стоять длина 2032мм. Мне "2032" заносить в таблицу КТС или создавать новую запись в справочнике (отличие только массы и длины), где мин будет 2032 и мах будет 2032? А это зависит от детализации справочника. Если будете искать в справочнике по вину, то я бы детализацию справочника привязывал к детализации вина. Если можно придумать отдельную маску для каждого варианта длины и тп - создаем отдельную запись в справочнике видов ТС. Нельзя - просто храним длину в КТС. Но поля я бы создал и там и там. Не уверен, насколько это допустимо, но вполне может быть, что машину оттюнинговали с изменением длины. В результате для вида ТС будет в справочнике видов ТС указана одна длина (как выехала с завода), а в КТС другая длина (после тюнинга) - как в техпаспорте (у меня ничего про длину не написано, но мало ли что понимаем под "техпаспортом" и какие они бывают). Названия полей я бы сделал разными, чтобы подчеркнуть разный смысл этих полей - стандартная длина данного вида ТС, и длина конкретного экземпляра ТС. Возможно, надо даже в КТС два поля для длины создать - фактическая длина и длина по "техпаспорту". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 15:12 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
s_ustinovНа вашем месте я бы в табличке вид тс (или базовая комплектация) хранил бы маску вина, которая позволяет приписать конкретное ТС к определенному виду. Спасибо. Просто думал сделать отдельную таблицу связей МАСКА, ТИП s_ustinovВ таблице КТС просто записывал бы вин в текстовое поле фиксированной длины. Если смотреть последнюю структуру, то так и сделал (текстовое поле ВИН длина 17 символов) s_ustinovИ после создания новой записи КТС и ввода вина на уровне приложения пробовал бы поискать по маске (логика поиска может быть сложной, так как структура вина неоднородная). Нашли один вид - его и предложили пользователю. Нашли несколько видов - предлагаем оператору несколько и заодно отправляем сообщение администратору БД, что есть вин, совпадающий с несколькими масками (вероятно, неправильно маски заданы). Не нашли ничего - предлагаем оператору проверить вин (возможно, он с ошибками) и ручками выбрать производителя и т.д. для выбора вида ТС. Если вообще нужного вида ТС нет - добавляется новый вид (марка, производитель и т.п.) в справочник. Понятно, так и задумывалось. s_ustinovПосле выбора пользователем вида ТС система показывает оператору, что будет записано в КТС - производитель, марка, вид и т.д. - на основании FK таблицы базовая комплектация КТС и связанных таблиц (запрос по нескольким таблицам или вьюшка). Оператор сравнивает с "техпаспортом", и если что-то не совпадает - корректирует соответствующее поле. И это поле не FK, а именно текстовое поле. Ну и администратор БД время от времени проверяет все расхождения - то ли ошибка в справочнике (неправильно написана марка, производитель и т.п.), то ли ошибка в конкретном "техпаспорте". В результате и данные правильные, и можно печатать документы с ошибкой в названии модели, повторяя ошибку из техпаспорта. Корректировать оператор сможет только определенные поля (масса, длина, количество сидений) s_ustinovНе уверен, насколько это допустимо, но вполне может быть, что машину оттюнинговали с изменением длины. В результате для вида ТС будет в справочнике видов ТС указана одна длина (как выехала с завода), а в КТС другая длина (после тюнинга) - как в техпаспорте (у меня ничего про длину не написано, но мало ли что понимаем под "техпаспортом" и какие они бывают). Одобрения типа имеет свой установленный бланк (одинаковый во всем мире) и набор характеристик (не от меня зависит). У одного производителя масса или длина ТИПа постоянная у другого варьируется в пределах от и до (в таблице Базовая комплектация КТС (рисунок со структурой) есть атрибуты - мин и мах для длины). Производитель получает одобрение ТИПа , а не ВАРИАНТа или ВЕРСИИ (я официально у завода производителя могу запросить только одобрение типа) поэтому он может в одобрении указывать предел, но когда авто выезжает с завода, производитель обязан нанести на табличку точную массу авто (а не предел как в одобрении типа). Создать новую запись в таблице базовая комплектация КТС? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 15:52 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
rikitikis_ustinovПосле выбора пользователем вида ТС система показывает оператору, что будет записано в КТС - производитель, марка, вид и т.д. - на основании FK таблицы базовая комплектация КТС и связанных таблиц (запрос по нескольким таблицам или вьюшка). Оператор сравнивает с "техпаспортом", и если что-то не совпадает - корректирует соответствующее поле. И это поле не FK, а именно текстовое поле. Ну и администратор БД время от времени проверяет все расхождения - то ли ошибка в справочнике (неправильно написана марка, производитель и т.п.), то ли ошибка в конкретном "техпаспорте". В результате и данные правильные, и можно печатать документы с ошибкой в названии модели, повторяя ошибку из техпаспорта. Корректировать оператор сможет только определенные поля (масса, длина, количество сидений) Ошибки и расхождения в документах. Например у меня в загранпаспорте фамилия латинницей написана одним способом, а в кредитке - другим. Всегда желательно учитывать ситуацию, что в справочнике написано одно название, и написано корректно. А в документе написано другое название в результате ошибки или по другим причинам. И при этом в базе надо сохранить именно то название, которое в документе. Если оператор может корректировать только определенные поля - что он должен делать в такой ситуации? rikitikis_ustinovНе уверен, насколько это допустимо, но вполне может быть, что машину оттюнинговали с изменением длины. В результате для вида ТС будет в справочнике видов ТС указана одна длина (как выехала с завода), а в КТС другая длина (после тюнинга) - как в техпаспорте (у меня ничего про длину не написано, но мало ли что понимаем под "техпаспортом" и какие они бывают). Одобрения типа имеет свой установленный бланк (одинаковый во всем мире) и набор характеристик (не от меня зависит). У одного производителя масса или длина ТИПа постоянная у другого варьируется в пределах от и до (в таблице Базовая комплектация КТС (рисунок со структурой) есть атрибуты - мин и мах для длины). Производитель получает одобрение ТИПа , а не ВАРИАНТа или ВЕРСИИ (я официально у завода производителя могу запросить только одобрение типа) поэтому он может в одобрении указывать предел, но когда авто выезжает с завода, производитель обязан нанести на табличку точную массу авто (а не предел как в одобрении типа). Создать новую запись в таблице базовая комплектация КТС? Я раньше сказал свое мнение. Новая запись в таблице базовая комплектация КТС создается только в том случае, если для неё можно придумать уникальную маску ВИН. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 16:09 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
Уточнения по структуре Все таблицы, кроме КТС - это справочник отличный первичный ключ для справочника - номер одобрения типа, вариант, версия (обязательно эти 3 параметра вместе) Таблица КТС - это рабочая таблица оператора (какие поля там должны быть?) нам нужно записать конкретный автомобиль. Пример с длиной и массой не очень подходящий, вспомнил еще один пример. Завод производитель указывает оригинальные (те, что идут с завода) шины и диски, для определенного (номера одобрения типа, варианта, версии) авто - эти данные занесены в справочник (таблица "Ось"), но также производитель всегда прописывает еще 2-3 варианта на выбор владельца авто. Так вот оператор должен указать фактические данные по шинам и дискам, я ему могу предложить для выбора только оригинальные. Вот собственно и вопрос, рабочая таблица КТС должна иметь один ключ id - для дальнейшего использования, а остальные 200 полей текстовые, где заноситься фактическая информация (плюс добавляются таблицы по двигателю, осям, кузову, выбросам, табличкам) или поле с ключом id и поле с ключом из таблицы "Базовая комплектация КТС", но тогда фактические данные оформлять как добавление новой записи в справочник? заметьте про ВИН не слова ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 16:58 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
s_ustinovОшибки и расхождения в документах. Например у меня в загранпаспорте фамилия латинницей написана одним способом, а в кредитке - другим. Паспорт выдавали больше 15 лет назад? правила транслитерации изменились у меня такая же ситуация. s_ustinov Всегда желательно учитывать ситуацию, что в справочнике написано одно название, и написано корректно. А в документе написано другое название в результате ошибки или по другим причинам . И при этом в базе надо сохранить именно то название, которое в документе. Подскажите как это реализовать? Отдельная таблица сравнения? rikitikiЕсли оператор может корректировать только определенные поля - что он должен делать в такой ситуации?Иногда просто признать свою ошибку. rikitikiЯ раньше сказал свое мнение. Новая запись в таблице базовая комплектация КТС создается только в том случае, если для неё можно придумать уникальную маску ВИН. Пока писал предыдущее сообщение, не видел, что Вы написали свой ответ. Значит рабочая таблица с полями + структура справочника? Тогда вопрос по справочнику, оставляем во всех таблицах только id_типа, id_Вар_вер? Что делать с таблицей производитель, марка, коммерческое название? какие FK там делать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 17:26 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
RikitikiУточнения по структуре Все таблицы, кроме КТС - это справочник отличный первичный ключ для справочника - номер одобрения типа, вариант, версия (обязательно эти 3 параметра вместе) Таблица КТС - это рабочая таблица оператора (какие поля там должны быть?) нам нужно записать конкретный автомобиль. Пример с длиной и массой не очень подходящий, вспомнил еще один пример. Завод производитель указывает оригинальные (те, что идут с завода) шины и диски, для определенного (номера одобрения типа, варианта, версии) авто - эти данные занесены в справочник (таблица "Ось"), но также производитель всегда прописывает еще 2-3 варианта на выбор владельца авто. Так вот оператор должен указать фактические данные по шинам и дискам, я ему могу предложить для выбора только оригинальные. Вот собственно и вопрос, рабочая таблица КТС должна иметь один ключ id - для дальнейшего использования, а остальные 200 полей текстовые, где заноситься фактическая информация (плюс добавляются таблицы по двигателю, осям, кузову, выбросам, табличкам) или поле с ключом id и поле с ключом из таблицы "Базовая комплектация КТС", но тогда фактические данные оформлять как добавление новой записи в справочник? заметьте про ВИН не слова Непонятно. Нарисуйте два варианта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 18:28 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
Rikitikis_ustinov Всегда желательно учитывать ситуацию, что в справочнике написано одно название, и написано корректно. А в документе написано другое название в результате ошибки или по другим причинам . И при этом в базе надо сохранить именно то название, которое в документе. Подскажите как это реализовать? Отдельная таблица сравнения? Зачем отдельная таблица? RikitikirikitikiЕсли оператор может корректировать только определенные поля - что он должен делать в такой ситуации?Иногда просто признать свою ошибку. Если документ выдал некий гос орган - можно убить кучу времени, получая правильный вариант документа. Еще раз - речь не идет об ошибке оператора. Мы живем в реальном мире, где сущность одна (тип автомобиля), а вот название этой сущности в конкретном документе - другое. И при создании и печати пакета документов надо использовать не правильное название из справочника, а неправильное из документа. RikitikirikitikiЯ раньше сказал свое мнение. Новая запись в таблице базовая комплектация КТС создается только в том случае, если для неё можно придумать уникальную маску ВИН. Пока писал предыдущее сообщение, не видел, что Вы написали свой ответ. Значит рабочая таблица с полями + структура справочника? Тогда вопрос по справочнику, оставляем во всех таблицах только id_типа, id_Вар_вер? Что делать с таблицей производитель, марка, коммерческое название? какие FK там делать? ?????? Просто нарисуйте схему БД без избыточности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 18:35 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
s_ustinov, структуру нарисую уже завтра, вечером пишу с телефона ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 18:47 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
Rikitiki... пропущено Int не всегда хорошо, пример Treeview - ключи начинаются с символа. ... пропущено В Вашем случае это не играет роли. VIN может начинаться с цифры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 20:15 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
Справочник ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2017, 10:00 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
Рабочая таблица ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2017, 10:02 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
Rikitiki, тип, марка, название, производитель - надо выстроить цепочкой, как было в самом начале. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2017, 12:55 |
|
||
|
БД транспортное средство
|
|||
|---|---|---|---|
|
#18+
s_ustinov, так? не могу понять какие связи делать Марка имеет несколько Коммерческих названий Коммерческое название может иметь несколько типов Но коммерческого названия может и не быть (часто у китайцев, у большинства прицепов) Как эти 3 таблицы связать между собой? Может какую-то таблицу связей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2017, 13:28 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=39399538&tid=1540210]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
65ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 403ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...