Правильное — враг хорошего
Уж сколько раз твердили миру: если вы не понимаете, почему программа написана именно так — возможно, проблема не в разработчике, а в том, что именно вы не понимаете, почему программа написана так.
Вот свежий пример: база данных сети магазинов с отделами. И начинается: хорошие и плохие преподаватели, нормальная форма, ненормальная форма, а почему не отдельная таблица, а почему не отдельные поля…
А вы точно разобрались, что именно должна хранить эта БД и как с ней работает софт?
Если вам преимущественно нужно делать выборку по одному отделу, потом по другому отделу, потом по третьему — логично, что тут удобнее список отделов и связка этого списка с таблицей, скажем, магазинов: это сокращает объём выборок. Наверняка именно так вас учили.
Если вам нужно делать одну большую выборку по магазинам и получить списки отделов в них, то удобнее забить отделы прямо в одну плоскую таблицу, чем вести ещё отдельно таблицу отделов и таблицу связок: это элементарно лишние операции поиска в тех таблицах. Вы же не делаете таблицу имён, таблицу фамилий и таблицу отчеств со всеми связками, а просто пишете: «Иванов Иван Иванович». И найти потом всех «Ивановых» тоже несложно будет, верно?
Почему не сделать отдельные поля? Да хотя бы потому, что добавить в строку ещё два отдела — задача элементарная, а вот добавить два новых поля, по две новых переменных для работы с ними во все функции и в интерфейс — это уже доработка ПО с потенциальным внесением новых глюков и багов, отладкой, тестированием, бюджетами и внедрением.
А вот если бы вам надо было хранить и получать организационную структуру магазинов — это могла бы быть вообще иерархия вложенных объектов в NoSQL-базе, от банальной LDAP до модной нынче MongoDB.
Всё зависит от того, какая задача стояла перед создателями базы.
Но вы не хотите вникать в какую-то там задачу. Вы же дипломированные специалисты, прослушавшие курсы лекций по нормализации, и бумажка об окончании есть, наверное. Вы знаете, как правильно, как неправильно, у вас огромный опыт в написании лабораторных, рефератов и сдаче зачётов.
Вот только вы, сами того не замечая, уподобляетесь тёткам — выпускницам «компьютерных курсов», которые раз и навсегда твёрдо запомнили: чтобы скопировать документ с диска на флешку, надо открыть его в Ворде и «сохранить как». Заодно вы убедитесь, что это именно тот документ, который нужно, и точно не ярлык, поэтому именно такой способ будет единственно верным, а все эти «перетаскивания файлов» или, ещё хуже, «синие панельки с текстом» — ересь и скверна, так делать нельзя, потому что это неправильно!
В доказательство тётка тоже может предъявить сертификат о прохождении курсов: у тебя, глупый админ, такого нет! И попробуй оспорь…
Вот свежий пример: база данных сети магазинов с отделами. И начинается: хорошие и плохие преподаватели, нормальная форма, ненормальная форма, а почему не отдельная таблица, а почему не отдельные поля…
А вы точно разобрались, что именно должна хранить эта БД и как с ней работает софт?
Если вам преимущественно нужно делать выборку по одному отделу, потом по другому отделу, потом по третьему — логично, что тут удобнее список отделов и связка этого списка с таблицей, скажем, магазинов: это сокращает объём выборок. Наверняка именно так вас учили.
Если вам нужно делать одну большую выборку по магазинам и получить списки отделов в них, то удобнее забить отделы прямо в одну плоскую таблицу, чем вести ещё отдельно таблицу отделов и таблицу связок: это элементарно лишние операции поиска в тех таблицах. Вы же не делаете таблицу имён, таблицу фамилий и таблицу отчеств со всеми связками, а просто пишете: «Иванов Иван Иванович». И найти потом всех «Ивановых» тоже несложно будет, верно?
Почему не сделать отдельные поля? Да хотя бы потому, что добавить в строку ещё два отдела — задача элементарная, а вот добавить два новых поля, по две новых переменных для работы с ними во все функции и в интерфейс — это уже доработка ПО с потенциальным внесением новых глюков и багов, отладкой, тестированием, бюджетами и внедрением.
А вот если бы вам надо было хранить и получать организационную структуру магазинов — это могла бы быть вообще иерархия вложенных объектов в NoSQL-базе, от банальной LDAP до модной нынче MongoDB.
Всё зависит от того, какая задача стояла перед создателями базы.
Но вы не хотите вникать в какую-то там задачу. Вы же дипломированные специалисты, прослушавшие курсы лекций по нормализации, и бумажка об окончании есть, наверное. Вы знаете, как правильно, как неправильно, у вас огромный опыт в написании лабораторных, рефератов и сдаче зачётов.
Вот только вы, сами того не замечая, уподобляетесь тёткам — выпускницам «компьютерных курсов», которые раз и навсегда твёрдо запомнили: чтобы скопировать документ с диска на флешку, надо открыть его в Ворде и «сохранить как». Заодно вы убедитесь, что это именно тот документ, который нужно, и точно не ярлык, поэтому именно такой способ будет единственно верным, а все эти «перетаскивания файлов» или, ещё хуже, «синие панельки с текстом» — ересь и скверна, так делать нельзя, потому что это неправильно!
В доказательство тётка тоже может предъявить сертификат о прохождении курсов: у тебя, глупый админ, такого нет! И попробуй оспорь…
0 комментариев