|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
В теме, которую я поднимал ранее на этом форуме я просил подсказать онлайн-ресурсы, где можно было бы попрактиковаться в написании запросов. Мне скинули один из сайтов, после чего было заявлено, что БД, под которую составлены упражнения на том сайте спроектирована крайне неграмотно. Вот описание той БД: состоит из четырех таблиц: Product(maker, model, type) PC(code, model, speed, ram, hd, cd, price) Laptop(code, model, speed, ram, hd, screen, price) Printer(code, model, color, type, price) Таблица Product представляет производителя (maker), номер модели (model) и тип (PC — ПК, Laptop — портативный компьютер или Printer — принтер). Предполагается, что в этой таблице номера моделей уникальны для всех производителей и типов продуктов. В таблице PC для каждого номера модели, обозначающего ПК, указаны скорость процессора — speed (МГерц), общий объем оперативной памяти - ram (Мбайт), размер диска — hd (в Гбайт), скорость считывающего устройства - cd (например, '4х') и цена — price. Таблица Laptop аналогична таблице РС за исключением того, что вместо скорости CD-привода содержит размер экрана — screen (в дюймах). В таблице Printer для каждой модели принтера указывается, является ли он цветным — color ('y', если цветной), тип принтера — type (лазерный — Laser, струйный — Jet или матричный — Matrix) и цена — price. Что бы вы изменили в дизайне данной БД? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2018, 09:58 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
люди правы. препод за такую структуру побьет. во первых примарным ключом должно быть поле ID. model у разных поставщиков запросто может совпасть. во вторых price должно быть в товаре. вообще, если это учебная хрень, то вероятно от тебя хотят более нормализованную структуру. т.е. таблицу products, product_attributes, attriputes2product делать отдельные таблицы под каждый тип товара в принципе допускается, но обычно это делается ради упрощения (оптимизации) запросов, т.е. если предполагаются какие-то проблемы с классическим денормализованным подходом. т.е. препод спросит почему структура денормализованна и ты должен будешь внятно объяснить почему ты наплодил столько таблиц, если достаточно три. и куда ты с такой структурой собрался планшеты записывать ... ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2018, 10:19 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
hck1во первых примарным ключом должно быть поле ID. model у разных поставщиков запросто может совпасть Не лучше ли сделать составной PK: maker+model? Если сделать ключом ID, то таким образом никаких ограничений на дублируемость не задается. А при составном ключе имеется строгое ограничение на пары (производитель, модель) "т.е. таблицу products, product_attributes, attriputes2product" чем product_attributes отличается от attriputes2product? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2018, 11:33 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
Dmi_triНе лучше ли сделать составной PK: maker+model? Если сделать ключом ID, то таким образом никаких ограничений на дублируемость не задается. А при составном ключе имеется строгое ограничение на пары (производитель, модель) нет, составной ключ зло и уже многие года не модное. foreign key на ID будет занимать пару байт, а в случае с составным ключем тебе везде бы пришлось и производителя и модель пихать которые, на порядок больше места сожрут. плюс многие тулзы, типа отчетные, репликаторы не понимают как джоинить составные таблицы с составными ключами. Dmi_triчем product_attributes отличается от attriputes2product? срочно беги читать про many-to-many relationship и про нормализацию. вкратце: product_attributes справочник атрибутов, там у тебя будет атрибут RAM 8Gb, attributes2product будет три колонки id, product_id, product_attribute_id. в итоге в атрибутах одна запись RAM 8Gb а в attributes2product записи которые связывают продукты (PC, Laptops, планшеты) с памятью на 8 гб. P.S. еще раз, id должно быть в абсолютно каждой таблице. нормальный primary key в каждой таблице сильно упростит жизнь, когда надо будет какие-то мутные инструменты прикручивать или нарисовать синхронизацию с каким-нибудь 1с. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2018, 13:54 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
Окей, вопрос немного в сторону. Есть такое задание: Найти производителей, которые выпускают более одной модели, при этом все выпускаемые производителем модели являются продуктами одного типа. Вывести: maker, type Я написал следующий запрос: SELECT maker, type FROM product GROUP BY maker, type HAVING COUNT(*)>1 Почему это неверно? В ответе требуют вот такую запись: SELECT maker, MAX(type) FROM product GROUP BY maker HAVING COUNT(DISTINCT type) = 1 AND COUNT(model) > 1 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2018, 14:03 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
hck1многие тулзы, типа отчетные, репликаторы не понимают как джоинить составные таблицы с составными ключами. А можно пример такого репликатора? Чисто на ткнуть пальцем и сказать "гы-гы". Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2018, 14:24 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
vendors (id [FK], name) - Производители product_types (id [FK], name) - типы продукты product_attribute_types (id [FK], name) - атрибуты продукта products (id [FK], name, vendor_id, product_type_id, model) - сами продукты product_details (id [FK], product_id, attribute_id, value) - состав продукта. Если нужен прайс, то держать в цену в товаре - моветон: sale_prices (id [FK], name, begin_date, end_date) sale_price_details (id, price_id, product_id, price) ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2018, 14:50 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovhck1многие тулзы, типа отчетные, репликаторы не понимают как джоинить составные таблицы с составными ключами. А можно пример такого репликатора? Чисто на ткнуть пальцем и сказать "гы-гы". например sqoop. да и вообще весь бигдата стек поколотит за композитные ключи. там все построено на ключ-значение и композитные ключ принесет адский гемор на ровном месте. Dmi_triОкей, вопрос немного в сторону. Есть такое задание: Найти производителей, которые выпускают более одной модели, при этом все выпускаемые производителем модели являются продуктами одного типа. Вывести: maker, type Я написал следующий запрос: SELECT maker, type FROM product GROUP BY maker, type HAVING COUNT(*)>1 Почему это неверно? В ответе требуют вот такую запись: SELECT maker, MAX(type) FROM product GROUP BY maker HAVING COUNT(DISTINCT type) = 1 AND COUNT(model) > 1 хрен знает. может думано, что в продуктах может быть одна и та же модель, но разного цвета. тогда их запрос менее кривой, чем твой. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2018, 16:14 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
Dmi_triПочему это неверно? Потому что ты сделал условие "выпускают более одной модели", но полностью проигнорировал "все выпускаемые производителем модели являются продуктами одного типа". Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2018, 18:08 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovDmi_triПочему это неверно? Потому что ты сделал условие "выпускают более одной модели", но полностью проигнорировал "все выпускаемые производителем модели являются продуктами одного типа". в этом плане все у него нормально: GROUP BY maker, type вероятней всего тот кто такую шикарную структуру нарисовал, не знал что в GROUP BY можно несколько полей писать. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2018, 18:47 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
hck1в этом плане все у него нормально: GROUP BY maker, *type* Нет, в этом плане он облажался с "найти производителей". Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2018, 19:13 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
makertypemodelSamsungраскладушкаХ450SamsungраскладушкаХ460SamsungкирпичА10SamsungкирпичА20 Его запрос выведет makertypeSamsungраскладушкаSamsungкирпич а это явно неправильно. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2018, 19:21 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovЕго запрос выведет makertypeSamsungраскладушкаSamsungкирпич а это явно неправильно. это все таки другая проблема. если вообще проблема. Dimitry Sibiryakov... но полностью проигнорировал "все выпускаемые производителем модели являются продуктами одного типа". GROUP BY все же это учел ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2018, 19:44 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
Dmi_tri Мне скинули один из сайтов, после чего было заявлено, что БД, под которую составлены упражнения на том сайте спроектирована крайне неграмотно.Сколько загадочности-то на ровном месте . Dmi_triЧто бы вы изменили в дизайне данной БД?Ничего. Модель очень подходит для того, для чего она сделана. А вот ваши "лучшести" вы не озвучили. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2018, 00:14 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
Гавриленко Сергей АлексеевичНичего. Модель очень подходит для того, для чего она сделана. А вот ваши "лучшести" вы не озвучили. вы не правы. молодежь должна на правильных структурах учится, они то что видели реализуют, когда на первой же работе требуют закрыть спринт. времени то разобраться не дадут. иначе 1с так и останется самым распространенным "продуктом". ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2018, 01:35 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
hck1Гавриленко Сергей АлексеевичНичего. Модель очень подходит для того, для чего она сделана. А вот ваши "лучшести" вы не озвучили. вы не правы. молодежь должна на правильных структурах учится, они то что видели реализуют, когда на первой же работе требуют закрыть спринт. времени то разобраться не дадут. иначе 1с так и останется самым распространенным "продуктом".Правильная структура? Это что за бред такой? Вот что правильнее, молоток или овощерезка? А те, у кого молодежи на первой же работе позволено какую-то там структуру за спринт да еще и без присмотра реализовывать... ну, пусть страдают, чо. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2018, 02:26 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
Гавриленко Сергей Алексеевичhck1пропущено... вы не правы. молодежь должна на правильных структурах учится, они то что видели реализуют, когда на первой же работе требуют закрыть спринт. времени то разобраться не дадут. иначе 1с так и останется самым распространенным "продуктом".Правильная структура? Это что за бред такой? Вот что правильнее, молоток или овощерезка? А те, у кого молодежи на первой же работе позволено какую-то там структуру за спринт да еще и без присмотра реализовывать... ну, пусть страдают, чо. студенты хотят курсач нахаляву ... |
|||
:
Нравится:
Не нравится:
|
|||
02.01.2019, 20:16 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
Насколько я понимаю, речь идет от БД от sql-ex Так она же учебная, и предназначена для отработки навыков запросов с джойнами. Брать ее за образец - бесмысленно, у нее другая задача, и в рамках своей задачи та база прекрасно подходит. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2019, 11:50 |
|
База данных "Компьютерная фирма"
|
|||
---|---|---|---|
#18+
там есть еще более кривая БД корабли. В которой есть факты по кораблям которых вообще нету в справочнике кораблей. После написания пары десятков запросов на этой базе мои студенты с кровью и потом понимают на практике почему нужна нормализация и целостность модели данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2019, 14:48 |
|
|
start [/forum/topic.php?fid=32&msg=39755130&tid=1539970]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
41ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
others: | 269ms |
total: | 404ms |
0 / 0 |