Рефакторинг на БД
23 отговора
915 прегледа
Рефакторинг на БД
Казахте, че искахте флеймче - ето едно от мен.
Бази от данни или по точно схемата на базата.
Рефакторинг на схемата на БД, кога трябва да се прави и изобщо трябва ли да се прави.
В предния пост видях нещо, пуснато от Дешев - [линк]
Наскоро четах по темата и от Martin Fowler - [линк]
Та реших и аз да се изкажа по темата, и да се заформи флейма.
Преди няколко години бях скепчитен относно идеите на XP, unit testing и разни други изгъзици (така им викахме на времето с колеги). Ама ги възприех(ме), лека по-лека, с течение на времето. Даже и ми харесаха, даже и работят и са полезни голяма част тези идеи.
Обаче не мога да се съглася с идеите за "дизайн" на схемата на БД, рефакторинг, еволюционно разработване и пр. изгъзици (за това и след време няма да си променя мнението).
Според мен дизайн на базата от данни няма. Такова понятие няма и тотално грешно. И от там идва целия проблем и последващите рефакторинг, еволюционен дизайн и пр. изгъзици. Има нормализация. Нормализацията е процес. При това не е творчески процес. Ако 10 човека направят "дизайн" на дадена схема, накрая трябва да се получи една и съща схема. Базата трябва да влезе в трета нормална форма. Иначе винаги ще има проблеми. Изключваме Data Warehouses, където данните се "наливат" рядко и базите са оптимизирани за заявки (Select).
Проблемът се крие, че почти никой не знае какво е това нормализация, денормализация и пр. Липсва теорията на хората, които се занимават с това. Виждал съм много добри програмисти - колеги, който като опре до БД и умират прави. Почват да разсъждават в ОО парадигми, в разни други техни си измишльотини и пр. Бисерите, които съм виждал по темата, са неизброими и могат да шашнат всеки, който е чувал малко за нормализация (тука трябва да кажа едно благодарско на 2-3 ма ст. ас. и проф. Бъчваров, които ми водеха тези дисциплини на времето). Елементарния трик е да споменеш "Трета нормална форма" и те като питат "Какво е трета нормална форма?", да отговориш "От третия път може и да стане". За съжаление, такава е действителността.
Сега, по статиите.
Първият автор говори за рефакторинг и дава като примери елементарни грешки. Абсолютно съм съгласен с него, обаче въпроса е защо се е стигнало до там. Тези неща трябва да се правят по време на "дизайна", а не след това, защото става голяма каша и промяната е много трудна. Същият автори си го е казал в статията де - [линк]. Въпросните неща се преподават(ха поне навремето) интересно що никой не ги ползва. Може би се преподават на твърде теоретично ниво, а обяснено в XP по хваща око.
Martin Fowler направо надминава себе си. Чел съм го и преди и има ценни идеи. Обаче с идеите си за еволюционен дизайн на БД направо избива рибата. Ее, не мога да се съглася с идеите му. Авторът говори за отделно копие за всеки разработчик, после за смесване на работата на всички разработчици и др. такива шантави неща. Всичко това изисква допълнителни ресурси и време.
Правилният подход, според мен, е нормализиране на данните в началото. И после добавяне на поленца, защото, най-вероятно, все ще изникне нещо. Ако в един проект започне да се променя схемата на базата, пиши го закъсал. Обикновено, винаги се добавя някое и други поле, но това не е проблем.
Става ли за флейм или не става.
Бази от данни или по точно схемата на базата.
Рефакторинг на схемата на БД, кога трябва да се прави и изобщо трябва ли да се прави.
В предния пост видях нещо, пуснато от Дешев - [линк]
Наскоро четах по темата и от Martin Fowler - [линк]
Та реших и аз да се изкажа по темата, и да се заформи флейма.
Преди няколко години бях скепчитен относно идеите на XP, unit testing и разни други изгъзици (така им викахме на времето с колеги). Ама ги възприех(ме), лека по-лека, с течение на времето. Даже и ми харесаха, даже и работят и са полезни голяма част тези идеи.
Обаче не мога да се съглася с идеите за "дизайн" на схемата на БД, рефакторинг, еволюционно разработване и пр. изгъзици (за това и след време няма да си променя мнението).
Според мен дизайн на базата от данни няма. Такова понятие няма и тотално грешно. И от там идва целия проблем и последващите рефакторинг, еволюционен дизайн и пр. изгъзици. Има нормализация. Нормализацията е процес. При това не е творчески процес. Ако 10 човека направят "дизайн" на дадена схема, накрая трябва да се получи една и съща схема. Базата трябва да влезе в трета нормална форма. Иначе винаги ще има проблеми. Изключваме Data Warehouses, където данните се "наливат" рядко и базите са оптимизирани за заявки (Select).
Проблемът се крие, че почти никой не знае какво е това нормализация, денормализация и пр. Липсва теорията на хората, които се занимават с това. Виждал съм много добри програмисти - колеги, който като опре до БД и умират прави. Почват да разсъждават в ОО парадигми, в разни други техни си измишльотини и пр. Бисерите, които съм виждал по темата, са неизброими и могат да шашнат всеки, който е чувал малко за нормализация (тука трябва да кажа едно благодарско на 2-3 ма ст. ас. и проф. Бъчваров, които ми водеха тези дисциплини на времето). Елементарния трик е да споменеш "Трета нормална форма" и те като питат "Какво е трета нормална форма?", да отговориш "От третия път може и да стане". За съжаление, такава е действителността.
Сега, по статиите.
Първият автор говори за рефакторинг и дава като примери елементарни грешки. Абсолютно съм съгласен с него, обаче въпроса е защо се е стигнало до там. Тези неща трябва да се правят по време на "дизайна", а не след това, защото става голяма каша и промяната е много трудна. Същият автори си го е казал в статията де - [линк]. Въпросните неща се преподават(ха поне навремето) интересно що никой не ги ползва. Може би се преподават на твърде теоретично ниво, а обяснено в XP по хваща око.
Martin Fowler направо надминава себе си. Чел съм го и преди и има ценни идеи. Обаче с идеите си за еволюционен дизайн на БД направо избива рибата. Ее, не мога да се съглася с идеите му. Авторът говори за отделно копие за всеки разработчик, после за смесване на работата на всички разработчици и др. такива шантави неща. Всичко това изисква допълнителни ресурси и време.
Правилният подход, според мен, е нормализиране на данните в началото. И после добавяне на поленца, защото, най-вероятно, все ще изникне нещо. Ако в един проект започне да се променя схемата на базата, пиши го закъсал. Обикновено, винаги се добавя някое и други поле, но това не е проблем.
Става ли за флейм или не става.
Re: Рефакторинг на БД
Ами според мен даже и когато става дума за ОО дизайн, с тия малки механични промени, просто няма как да стане принципно ново и добро нещо.
Те тия малките рефакторинги, програмистите си ги правят непрекъснато без специално да сядат и да рефакторират.
Познавам хора, дето като се промени нещо спецификацията, и започват да пишат отначало write-only код. Много е яко. Могат да предвидят с огромна точност колко време ще им отнеме, и шефовете са доволни.
Та за такива хора (преводачи от анг. на SQL) сигурно ще е полезно.
Също вече съм писал тука, че когато проектирам нещо, се водя от съвсем други критерии.
Като например това за базата дани, което си написал.
Абе номера е все повече индийци да могат да 'проектират' и да разработват 'еволюционно' софтуер, а М. Фоулер да си прибира парите. Нещо като МС със VB.
Сигнатура!
Те тия малките рефакторинги, програмистите си ги правят непрекъснато без специално да сядат и да рефакторират.
Познавам хора, дето като се промени нещо спецификацията, и започват да пишат отначало write-only код. Много е яко. Могат да предвидят с огромна точност колко време ще им отнеме, и шефовете са доволни.
Та за такива хора (преводачи от анг. на SQL) сигурно ще е полезно.
Също вече съм писал тука, че когато проектирам нещо, се водя от съвсем други критерии.
Като например това за базата дани, което си написал.
Абе номера е все повече индийци да могат да 'проектират' и да разработват 'еволюционно' софтуер, а М. Фоулер да си прибира парите. Нещо като МС със VB.
Сигнатура!
Re: Рефакторинг на БД
За кода като цяло съм съгласен, че рефакторинга помага. С малки промени може да направиш системата по-бърза, кодът да се поддържа по-лесно и да бъде по-четим. Изобщо рефакторинга на кода е хубаво нещо, но не трябва да се прекалява с него. Освен това, ако имаш unit testing няма нужда да се притесняваш, че ще счупиш нещо.
Докато рефакторинга да БД е много трудоемко нещо и ако трябва да правиш рефакторинг на БД, не е ли по-добре да почнеш от начало (става въпрос, ако променяш схемата из основи). Той и оня автор си го е казал, че е трудоемко нещо.
Докато рефакторинга да БД е много трудоемко нещо и ако трябва да правиш рефакторинг на БД, не е ли по-добре да почнеш от начало (става въпрос, ако променяш схемата из основи). Той и оня автор си го е казал, че е трудоемко нещо.
Re: Рефакторинг на БД
Нека направим разлика между флейма и нормалната дискусия. Засега още не сме припалили горелките.
За скептицизма няма да си кривя душата: когато преди над 2 години един колега загатваше за практики като рефакторинг аз се подхилквах и се бъзиках. Кой да знае докъде ще я докарам а.
За "дизайна" и организацията на данните в БД не искам да задълбавам. Първо, че съм бос, въпреки че съм чувал за 3-та нормална форма. Второ темата е обширна и има не една книга или статия по въпроса. От статии като тази само ми става ясно колко малко знам за базите и релационния модел.
Мисля, че основата на мнението ти е това:
И според мен няма дизайн на базата. Няма и дизайн на обектите. Има дизайн на цялото. Признавам, схемата на една база данни е традиционно трудно за променяне "нещо". Трудно но не невъзможно. Ще опитам в друг по-конкретен пост да разкажа какво съм опитвал в тази област.
На нормализацията гледам по следния начин - това е просто друго име на елиминирането на дупликацията. Не съм сигурен дали крайният резултат е винаги един и същ - много често дори не знаем точно какъв ще е той след седмица. Май това е и основния проблем. Напълно съм съгласен, че е много хубаво да си нагласим всичко отначало, но често това изобщо не се получава. Не мога да не направя аналогия с дизайна на обектите. За мен проблемите са същите - хвърляме много усилия в първоначалния дизайн и след това го изхвърляме и преработваме когато установим, че не сме познали.
Как определяш, че добавянето на поленца е лесна и допустима промяна, а местенето на такива или променянето на някоя релация е недопустимо?
За статията на Фаулър и Прамод (Pramod Sadalage) за еволюционния ДБ дизайн си мисля, че описаните техники не са чак толкова невероятни и трудни за изпълнение.
За мен работата на всички разработчици в обща база данни е мърляво поведение. Смесването не е чак такова усилие. Прав си, че подготовката за тези практики иска ресурси и време, но се предполага, че тези усилия са си инвестиция, която ще се изплати по-нататък. Гледам доволен си, че пишеш тестове и си видял истинската им стойност -- предполагам, че може просто да опиташ да "инвестираш" и с базите по подобен начин. Аргументите "за" и "против" практиките са сходни.
--
Екстремно програмиране на български.
[линк]
За скептицизма няма да си кривя душата: когато преди над 2 години един колега загатваше за практики като рефакторинг аз се подхилквах и се бъзиках. Кой да знае докъде ще я докарам а.
За "дизайна" и организацията на данните в БД не искам да задълбавам. Първо, че съм бос, въпреки че съм чувал за 3-та нормална форма. Второ темата е обширна и има не една книга или статия по въпроса. От статии като тази само ми става ясно колко малко знам за базите и релационния модел.
Мисля, че основата на мнението ти е това:
В отговор на:Според мен дизайн на базата от данни няма. Такова понятие няма и тотално грешно. И от там идва целия проблем и последващите рефакторинг, еволюционен дизайн и пр. изгъзици. Има нормализация. Нормализацията е процес. При това не е творчески процес. Ако 10 човека направят "дизайн" на дадена схема, накрая трябва да се получи една и съща схема.
И според мен няма дизайн на базата. Няма и дизайн на обектите. Има дизайн на цялото. Признавам, схемата на една база данни е традиционно трудно за променяне "нещо". Трудно но не невъзможно. Ще опитам в друг по-конкретен пост да разкажа какво съм опитвал в тази област.
На нормализацията гледам по следния начин - това е просто друго име на елиминирането на дупликацията. Не съм сигурен дали крайният резултат е винаги един и същ - много често дори не знаем точно какъв ще е той след седмица. Май това е и основния проблем. Напълно съм съгласен, че е много хубаво да си нагласим всичко отначало, но често това изобщо не се получава. Не мога да не направя аналогия с дизайна на обектите. За мен проблемите са същите - хвърляме много усилия в първоначалния дизайн и след това го изхвърляме и преработваме когато установим, че не сме познали.
Как определяш, че добавянето на поленца е лесна и допустима промяна, а местенето на такива или променянето на някоя релация е недопустимо?
За статията на Фаулър и Прамод (Pramod Sadalage) за еволюционния ДБ дизайн си мисля, че описаните техники не са чак толкова невероятни и трудни за изпълнение.
В отговор на:Авторът говори за отделно копие за всеки разработчик, после за смесване на работата на всички разработчици и др. такива шантави неща. Всичко това изисква допълнителни ресурси и време.
За мен работата на всички разработчици в обща база данни е мърляво поведение. Смесването не е чак такова усилие. Прав си, че подготовката за тези практики иска ресурси и време, но се предполага, че тези усилия са си инвестиция, която ще се изплати по-нататък. Гледам доволен си, че пишеш тестове и си видял истинската им стойност -- предполагам, че може просто да опиташ да "инвестираш" и с базите по подобен начин. Аргументите "за" и "против" практиките са сходни.
--
Екстремно програмиране на български.
[линк]
Agile бази данни... експерименти
Обещах да напиша нещичко за моите авантюри в базите данни.
Мисля, че основния момент в който ми се пречупи мисълта беше когато осъзнах, че базата не е сървър, хранилище или идола, който пази данните. Базата е платформа: с всичките й библиотеки и програмен език. Тази платформа има 2 много важни компонента: кода и данните (изненадващо а?). Кода си е код и трябва да се пази.
Как се разви един мой уеб проект -- с PHP и MySQL. Първо държа да отбележа, че не съм еволюирал напълно дизайна и промените не бяха огромни, но все пак мисля, че показват правилната посока на действие.
1) SQL скриптовете, които създаваха базата седяха в отделна директория. Можех да създам база с нужната схема с просто изпълнение на команда от линукс конзолата. Тотално неприемливо е цъкането из базата с някакъв графичен инструмент, който променя данните и схемата и никъде(!!!) не оставя следи от действията си. Използвал съм само phpMyAdmin и след всяка стъпка съм си запазвал генерираната SQL команда, за да мога да я приложа по-късно.
2) Работех с копие на данните на локалната ми машина. Истинския сайт работеше... да кажем в измерението Х.
3) Юнит тестовете вървяха върху копие на базата. Копието се създаваше и инициализираше с данни на всяко изпълнение на тестовете. Мислех, че това ще е бавно, но MySQL понякога е обидно бърз. Правеха се допълнителни магии - конкатенация на скриптовете за създаване на схемата и тези за вкарване на данните, глобални замествания със sed за някои специфични имена -- сега се сещам за променянето на името на базата само. Заменянето се правеше защото използвах оригиналните скриптове за създаване на схемата и базата и исках да се застраховам срещу евентуални дефекти причинени от разлики в тестовата и реалната схеми. Всъщност вече се бях парил с такива и не исках да се мъча повече.
4) Промяна в базата водеше до неминуемо генериране на съответния скрипт. Било то просто ALTER TABLE извикване или по-сложна миграция. Тук ми помогна доста phpMyAdmin.
5) Отиването на моите промени до измерението Х се правеше от 2 скрипта. Единият използваше rsync, за да качи PHP скриптовете, вторият изпълняваше насъбраните промени за базата. Вторият беше отделен и умишлено изпълняван отделно защото малко ме беше страх
да не се осере нещо. Понякога правех и нещо на ръка, ако промяната ставаше много сложна.
Огромен фактор в предпазването ми от грешки изигра практиката да синхронизирам максимално често моето копие и това на сървъра в измерението Х. Така не се натрупваха големи промени и малката ми черепна кутия можеше да се справи с поемането на всичко.
Какво спечелих? Никакви дефекти и минимални усилия при интеграция, лесно синхронизиране и кратки рилийзи. Чувствах се agile - може би не на 10, но поне до 7. Имаше огромно удовлетворение -- особено като видех някой да се поти над гнусното vi на терминала към сървъра и да псува, че интернета е бавен. Мисля даже, че успях да наложа подобна култура на синхронизация със сървърите и да помогна и на другите.
Какво не направих? Имах мерак да направя отделен stage сървър, към когото да интегрирам и после да синхронизирам него с истинския сървър. Това си остана само мечта. По проекта работех сам и не съм видял доколко подобно нещо държи на блъсканици из базата и в кода. Поне имах тестове на компонентите, които зависеха от моите промени в базата и можех да проверя лесно дали промяната е интегрирана правилно. Работех с гаден опън-сорс продукт от тип "топка студени спагети" и му насаждах допълнителна функционалност. Това понякога ми охлаждаше мераците за рефакторинг.
--
Екстремно програмиране на български.
[линк]
Мисля, че основния момент в който ми се пречупи мисълта беше когато осъзнах, че базата не е сървър, хранилище или идола, който пази данните. Базата е платформа: с всичките й библиотеки и програмен език. Тази платформа има 2 много важни компонента: кода и данните (изненадващо а?). Кода си е код и трябва да се пази.
Как се разви един мой уеб проект -- с PHP и MySQL. Първо държа да отбележа, че не съм еволюирал напълно дизайна и промените не бяха огромни, но все пак мисля, че показват правилната посока на действие.
1) SQL скриптовете, които създаваха базата седяха в отделна директория. Можех да създам база с нужната схема с просто изпълнение на команда от линукс конзолата. Тотално неприемливо е цъкането из базата с някакъв графичен инструмент, който променя данните и схемата и никъде(!!!) не оставя следи от действията си. Използвал съм само phpMyAdmin и след всяка стъпка съм си запазвал генерираната SQL команда, за да мога да я приложа по-късно.
2) Работех с копие на данните на локалната ми машина. Истинския сайт работеше... да кажем в измерението Х.
3) Юнит тестовете вървяха върху копие на базата. Копието се създаваше и инициализираше с данни на всяко изпълнение на тестовете. Мислех, че това ще е бавно, но MySQL понякога е обидно бърз. Правеха се допълнителни магии - конкатенация на скриптовете за създаване на схемата и тези за вкарване на данните, глобални замествания със sed за някои специфични имена -- сега се сещам за променянето на името на базата само. Заменянето се правеше защото използвах оригиналните скриптове за създаване на схемата и базата и исках да се застраховам срещу евентуални дефекти причинени от разлики в тестовата и реалната схеми. Всъщност вече се бях парил с такива и не исках да се мъча повече.
4) Промяна в базата водеше до неминуемо генериране на съответния скрипт. Било то просто ALTER TABLE извикване или по-сложна миграция. Тук ми помогна доста phpMyAdmin.
5) Отиването на моите промени до измерението Х се правеше от 2 скрипта. Единият използваше rsync, за да качи PHP скриптовете, вторият изпълняваше насъбраните промени за базата. Вторият беше отделен и умишлено изпълняван отделно защото малко ме беше страх
да не се осере нещо. Понякога правех и нещо на ръка, ако промяната ставаше много сложна.
Огромен фактор в предпазването ми от грешки изигра практиката да синхронизирам максимално често моето копие и това на сървъра в измерението Х. Така не се натрупваха големи промени и малката ми черепна кутия можеше да се справи с поемането на всичко.
Какво спечелих? Никакви дефекти и минимални усилия при интеграция, лесно синхронизиране и кратки рилийзи. Чувствах се agile - може би не на 10, но поне до 7. Имаше огромно удовлетворение -- особено като видех някой да се поти над гнусното vi на терминала към сървъра и да псува, че интернета е бавен. Мисля даже, че успях да наложа подобна култура на синхронизация със сървърите и да помогна и на другите.
Какво не направих? Имах мерак да направя отделен stage сървър, към когото да интегрирам и после да синхронизирам него с истинския сървър. Това си остана само мечта. По проекта работех сам и не съм видял доколко подобно нещо държи на блъсканици из базата и в кода. Поне имах тестове на компонентите, които зависеха от моите промени в базата и можех да проверя лесно дали промяната е интегрирана правилно. Работех с гаден опън-сорс продукт от тип "топка студени спагети" и му насаждах допълнителна функционалност. Това понякога ми охлаждаше мераците за рефакторинг.
--
Екстремно програмиране на български.
[линк]
Re: Рефакторинг на БД
В отговор на:
Ами според мен даже и когато става дума за ОО дизайн, с тия малки механични промени, просто няма как да стане принципно ново и добро нещо.
Ами малките промени се натрупват и стават големи качествени изменения. Е понякога и не стават
.
В отговор на:
Те тия малките рефакторинги, програмистите си ги правят непрекъснато без специално да сядат и да рефакторират.
Правят ги малко по-осъзналите се програмисти. Има хора дето продължават да си кръщават всяка integer променлива i, всеки string - s, всеки StringBuilder sb. Тъжно. Рефакторинга за мен е като хигиената. Като не си мия ръцете най-много да се разболея от нещо. Защо повечето хора не се замислят като се къпят или си мият ръцете и зъбите, но не са склонни да си чистят кода? Това си е един полезен навик и толкова.
В отговор на:Абе номера е все повече индийци да могат да 'проектират' и да разработват 'еволюционно' софтуер, а М. Фоулер да си прибира парите. Нещо като МС със VB.
И VB е лошо защото...?--
Екстремно програмиране на български.
[линк]
Re: Рефакторинг на БД
дизайн на базата има и то какъв (цели продукти има) ...
нормализацията е само средство за премахване на излишество от данни (за 4-та и 5-та форма - от логическо естество или т.нар. multikeys) и обикновено се пренебрегва в дадени случаи
рефакторинг на базата се прави, но е доста трудно (според мене)
имал съм определени успехи, но не са генерални (т.е. да работят в общия случай) - специално за оракъл са полезни нещица от рода на [линк]
а за флейма - напоследък забелязвам, че това е единствената цел на хората във повечето форуми
жалкото е, че доста теми, които се нуждаят от отговори просто "потъват" без смислен или изобщо без никакъв отговор
нормализацията е само средство за премахване на излишество от данни (за 4-та и 5-та форма - от логическо естество или т.нар. multikeys) и обикновено се пренебрегва в дадени случаи
рефакторинг на базата се прави, но е доста трудно (според мене)
имал съм определени успехи, но не са генерални (т.е. да работят в общия случай) - специално за оракъл са полезни нещица от рода на [линк]
а за флейма - напоследък забелязвам, че това е единствената цел на хората във повечето форуми
жалкото е, че доста теми, които се нуждаят от отговори просто "потъват" без смислен или изобщо без никакъв отговор
Re: Рефакторинг на БД
И според мен няма дизайн на базата. Няма и дизайн на обектите. Има дизайн на цялото. Признавам, схемата на една база данни е традиционно трудно за променяне "нещо". Трудно но не невъзможно. Ще опитам в друг по-конкретен пост да разкажа какво съм опитвал в тази област.
Не е точно така.
Ако нарушиш правилата на нормализацията, ще имаш много сериозни проблеми с програмата. Обикновено, става пълна каша. По мои скромни наблюдения, 50% от проблемите идват, ако БД не е нормализирана. И при "дизайна" на схемата на БД може да направиш нещо по-няколко начина, но ако не го направиш по "нормалния" начин, ще имаш много сериозни проблеми. Също така, процесът на нормализация е добре описан, има си много ясни правила - 1НФ, 2НФ и пр.
От друга страна при ОО (или програмирането) също има доста ясни правила за дизайн. Но често ако не направиш нещо по правилния начин, то пак си работи. Т.е. тук можеш да правиш изключения без да имаш сериозни проблеми.
И накрая не съм съгласен с идеята ти за дизайн на цялото. Базата и кодът трябва да са разделени, което означа схемата на БД да не зависи дали ползваш PHP, Java или .NET. И накрая базата трябва да се грижи сама да бъде консистента, а не това да зависи от кода.
Как определяш, че добавянето на поленца е лесна и допустима промяна, а местенето на такива или променянето на някоя релация е недопустимо?
Добавянето на поленца, не изисква допълнителни усилия за рефакторинг, мигриране на данни и пр. Докато промяната на релации, местенето на полета от една таблица в друга си е направо мъка. И според мен затова в началото трябва да се хвърлят усилия към нормализирането на данните, което включва събиране на възможно най-пълна информация за данните, които ще се обработват. А не после като му дойде времето ще го мислим. Защото промени по GIU-то или по логиката се правят лесно в сравнение с промени в схемата на БД. И затова може да си позволим да отложим решението как ще изглежда някой екран, като опрем до него. Или да правим демо версии и да ги показваме на потребителя за промени, ако потребителя не хареса нещо.
За мен работата на всички разработчици в обща база данни е мърляво поведение. Смесването не е чак такова усилие. Прав си, че подготовката за тези практики иска ресурси и време, но се предполага, че тези усилия са си инвестиция, която ще се изплати по-нататък. Гледам доволен си, че пишеш тестове и си видял истинската им стойност -- предполагам, че може просто да опиташ да "инвестираш" и с базите по подобен начин. Аргументите "за" и "против" практиките са сходни.
Не е точно така.
Пак повтарям нормализацият е процес и доста по-лесен за следване, ако знаеш какво правиш, разбира се. Създаването на схемата на БД отнема по-малко от 5% от общото време. И според мен трябва да се прави в началото, а не после като му дойде времето да му мислим. Иначе всеки разработчик може да си има собствено копие, където да си има негови тестови данни, но да променя схемата е абсурд.
Или с други думи отношението правене на схемата на БД и кодиране е 1:10. И използването на въпросните методологии си е чиста загуба на време и ресурси.
Не е точно така.
Ако нарушиш правилата на нормализацията, ще имаш много сериозни проблеми с програмата. Обикновено, става пълна каша. По мои скромни наблюдения, 50% от проблемите идват, ако БД не е нормализирана. И при "дизайна" на схемата на БД може да направиш нещо по-няколко начина, но ако не го направиш по "нормалния" начин, ще имаш много сериозни проблеми. Също така, процесът на нормализация е добре описан, има си много ясни правила - 1НФ, 2НФ и пр.
От друга страна при ОО (или програмирането) също има доста ясни правила за дизайн. Но често ако не направиш нещо по правилния начин, то пак си работи. Т.е. тук можеш да правиш изключения без да имаш сериозни проблеми.
И накрая не съм съгласен с идеята ти за дизайн на цялото. Базата и кодът трябва да са разделени, което означа схемата на БД да не зависи дали ползваш PHP, Java или .NET. И накрая базата трябва да се грижи сама да бъде консистента, а не това да зависи от кода.
Как определяш, че добавянето на поленца е лесна и допустима промяна, а местенето на такива или променянето на някоя релация е недопустимо?
Добавянето на поленца, не изисква допълнителни усилия за рефакторинг, мигриране на данни и пр. Докато промяната на релации, местенето на полета от една таблица в друга си е направо мъка. И според мен затова в началото трябва да се хвърлят усилия към нормализирането на данните, което включва събиране на възможно най-пълна информация за данните, които ще се обработват. А не после като му дойде времето ще го мислим. Защото промени по GIU-то или по логиката се правят лесно в сравнение с промени в схемата на БД. И затова може да си позволим да отложим решението как ще изглежда някой екран, като опрем до него. Или да правим демо версии и да ги показваме на потребителя за промени, ако потребителя не хареса нещо.
За мен работата на всички разработчици в обща база данни е мърляво поведение. Смесването не е чак такова усилие. Прав си, че подготовката за тези практики иска ресурси и време, но се предполага, че тези усилия са си инвестиция, която ще се изплати по-нататък. Гледам доволен си, че пишеш тестове и си видял истинската им стойност -- предполагам, че може просто да опиташ да "инвестираш" и с базите по подобен начин. Аргументите "за" и "против" практиките са сходни.
Не е точно така.
Пак повтарям нормализацият е процес и доста по-лесен за следване, ако знаеш какво правиш, разбира се. Създаването на схемата на БД отнема по-малко от 5% от общото време. И според мен трябва да се прави в началото, а не после като му дойде времето да му мислим. Иначе всеки разработчик може да си има собствено копие, където да си има негови тестови данни, но да променя схемата е абсурд.
Или с други думи отношението правене на схемата на БД и кодиране е 1:10. И използването на въпросните методологии си е чиста загуба на време и ресурси.
Re: Agile бази данни... експерименти
Ами това за скриптовете си е задължително направо, няма смисъл от коментар.
Иначе не е ясно какво правим, въпреки че има много инструменти, които могат да направят дъмп на базата и после да я импортнат обратно, дори и само схемата без данните или само даните без схемата, по-желание на клиента. :-)
Копието се създаваше и инициализираше с данни на всяко изпълнение на тестовете.
Малко излишно, според мен веднъж дневно е достатъчно. Примерно 3 часа посред нощ е едно добро време да се стартират такива тестове. :-))
Правеха се допълнителни магии - конкатенация на скриптовете за създаване на схемата и тези за вкарване на данните, глобални замествания със sed за някои специфични имена -- сега се сещам за променянето на името на базата само. Заменянето се правеше защото използвах оригиналните скриптове за създаване на схемата и базата и исках да се застраховам срещу евентуални дефекти причинени от разлики в тестовата и реалната схеми. Всъщност вече се бях парил с такива и не исках да се мъча повече.
Похвално и правилен подход. Въпреки, че ако при малко по-добро планиране няма смисъл да се променя нищо. Въпросът е логичен. Защо базата ти се казва с едно име на дев. сървъра и с друго на прод. сървъра? И защо трябва да имаш различни неща, които да се променят със sed. Ми изкарай си ги на параметри и като правиш билд, казвай дали е прод. или дев. билд. Потребителя и паролата, разбира се, не трябва да са в скрипта, поради съображения за сигурност.
Т.е тука не изкривяваш ли малко нещата. Подходът е правилен да се заменят автоматично. Но въпросът е защо трябва да се стига до там и не е ли по-добре да преименуваш дев. базатата си, за да има същото име и същите параметри като прод. И не е ли по-лесно да направиш това и вместо да пишеш разни дълги и неразбрани команди със sed.
Промяна в базата водеше до неминуемо генериране на съответния скрипт. Било то просто ALTER TABLE извикване или по-сложна миграция. Тук ми помогна доста phpMyAdmin.
Абсолютно съгласен, то и така трябва да бъде, другото е садомазохизъм. :-)
Вторият беше отделен и умишлено изпълняван отделно защото малко ме беше страх да не се осере нещо. Понякога правех и нещо на ръка, ако промяната ставаше много сложна.
Ако имаше тест сървър (stage) нямаше да те е страх толкова. Щеше да караш по-смело.
И защо трябва да правиш неща на ръка. Това е гаден навик. На ръка трябва да се логваш само и да викаш главния скрипт. Иначе може да изтървеш нещо и после 2 седмици да се чудиш що не работи.
Иначе не е ясно какво правим, въпреки че има много инструменти, които могат да направят дъмп на базата и после да я импортнат обратно, дори и само схемата без данните или само даните без схемата, по-желание на клиента. :-)
Копието се създаваше и инициализираше с данни на всяко изпълнение на тестовете.
Малко излишно, според мен веднъж дневно е достатъчно. Примерно 3 часа посред нощ е едно добро време да се стартират такива тестове. :-))
Правеха се допълнителни магии - конкатенация на скриптовете за създаване на схемата и тези за вкарване на данните, глобални замествания със sed за някои специфични имена -- сега се сещам за променянето на името на базата само. Заменянето се правеше защото използвах оригиналните скриптове за създаване на схемата и базата и исках да се застраховам срещу евентуални дефекти причинени от разлики в тестовата и реалната схеми. Всъщност вече се бях парил с такива и не исках да се мъча повече.
Похвално и правилен подход. Въпреки, че ако при малко по-добро планиране няма смисъл да се променя нищо. Въпросът е логичен. Защо базата ти се казва с едно име на дев. сървъра и с друго на прод. сървъра? И защо трябва да имаш различни неща, които да се променят със sed. Ми изкарай си ги на параметри и като правиш билд, казвай дали е прод. или дев. билд. Потребителя и паролата, разбира се, не трябва да са в скрипта, поради съображения за сигурност.
Т.е тука не изкривяваш ли малко нещата. Подходът е правилен да се заменят автоматично. Но въпросът е защо трябва да се стига до там и не е ли по-добре да преименуваш дев. базатата си, за да има същото име и същите параметри като прод. И не е ли по-лесно да направиш това и вместо да пишеш разни дълги и неразбрани команди със sed.
Промяна в базата водеше до неминуемо генериране на съответния скрипт. Било то просто ALTER TABLE извикване или по-сложна миграция. Тук ми помогна доста phpMyAdmin.
Абсолютно съгласен, то и така трябва да бъде, другото е садомазохизъм. :-)
Вторият беше отделен и умишлено изпълняван отделно защото малко ме беше страх да не се осере нещо. Понякога правех и нещо на ръка, ако промяната ставаше много сложна.
Ако имаше тест сървър (stage) нямаше да те е страх толкова. Щеше да караш по-смело.
И защо трябва да правиш неща на ръка. Това е гаден навик. На ръка трябва да се логваш само и да викаш главния скрипт. Иначе може да изтървеш нещо и после 2 седмици да се чудиш що не работи.
в отговор на AcidMemory
#13
Re: Рефакторинг на БД
Разбира се, че има. В това няма съмнение.
Обаче подходът е сгрешен, според мен. Вместо да се види къде са корените на проблема, ние се борим с последствията му.
Обаче подходът е сгрешен, според мен. Вместо да се види къде са корените на проблема, ние се борим с последствията му.
Re: Рефакторинг на БД
Мисля, че разбрах проблема. Не се бях замислял и съм доволен от образувалите ми се мисли.
Напоследък все повече се убеждавам, че всичко в програмирането е обратна връзка. Всяка промяна трябва да се вижда веднага и да личи за какво е направена.
Какъв е проблема с базите данни, графичните интерфейси, мрежовите комуникации... ами не ги контролираме толкова добре колкото обектите и методите в програмата ни. Когато променя метод, от който зависят 2 обекта компилатора веднага ми казва! Когато променя таблица обаче, базата мълчи и се обажда чак когато опитам да използвам данните.
Как можем да превъзмогнем обектно-релационния импеданс (Скот Амблър му вика така)? Трябва ни механизъм, който да доведе базата -- нейната схема и данни във нашата програма. Той трябва да ни показва веднага когато възникне несъответствие между базата и кода на програмата. Основният проблем е, че имаме дупликация на знание - схемата е описана в базата и в кода, който използва данните. Единствено и само когато елиминираме тази дупликация и сме намерили начин да я тестваме ще можем да гарантираме, че промяната на двете места ще е еднакво евтина и с минимален риск.
Как да елиминираме дупликацията? Не знам! Напоследък ми се върти из главата някаква възможност за описване на структурата на данните с някакъв специфичен език. Няма значение дали ще е скриптов език, SQL, XML Schema, DTD, C++ или C# код. Важното е от него да мога да генерирам схемата на базата и механизма за достъп до данните от програмата. Трябва да имам и средства за генериране на мигриращи скриптове за данните и промяна на достъпа от програмата. Това описание е същинският код на системата. То трябва да се пази в SCM система и другото да се генерира като част от билда. То трябва да се тества от тестовете.
Други идеи? Конкретни реализации? Едва ли моето "описание" е нещо революционно. По-скоро съм го чел някъде и съм забравил източника. Подозирам все пак Дейв Хънт и Анди Томас -- the pragmatic programmers.
RealGuru, там дето си ме захапал за дизайна на цялото май не сме се разбрали. Не съм имал предвид физическо "връзване" на базата към програмния език. Идеята ми по-горе може да се разшири към езиково независимо описание и адаптирането на билд процеса към няколко езика. Дали усилията си струват? Ами всички сме виждали извращения като таблици със 200+ колони защото "полета се добавят лесно". Често изискванията се променят или програмата се надгражда. Системата може да бъде много по-гъвкава, проста и евтина ако дизайн решенията ни се водят от бизнес причини и не се спъват от страха да не би да счупим нещо.
--
Екстремно програмиране на български.
[линк]
Напоследък все повече се убеждавам, че всичко в програмирането е обратна връзка. Всяка промяна трябва да се вижда веднага и да личи за какво е направена.
Какъв е проблема с базите данни, графичните интерфейси, мрежовите комуникации... ами не ги контролираме толкова добре колкото обектите и методите в програмата ни. Когато променя метод, от който зависят 2 обекта компилатора веднага ми казва! Когато променя таблица обаче, базата мълчи и се обажда чак когато опитам да използвам данните.
Как можем да превъзмогнем обектно-релационния импеданс (Скот Амблър му вика така)? Трябва ни механизъм, който да доведе базата -- нейната схема и данни във нашата програма. Той трябва да ни показва веднага когато възникне несъответствие между базата и кода на програмата. Основният проблем е, че имаме дупликация на знание - схемата е описана в базата и в кода, който използва данните. Единствено и само когато елиминираме тази дупликация и сме намерили начин да я тестваме ще можем да гарантираме, че промяната на двете места ще е еднакво евтина и с минимален риск.
Как да елиминираме дупликацията? Не знам! Напоследък ми се върти из главата някаква възможност за описване на структурата на данните с някакъв специфичен език. Няма значение дали ще е скриптов език, SQL, XML Schema, DTD, C++ или C# код. Важното е от него да мога да генерирам схемата на базата и механизма за достъп до данните от програмата. Трябва да имам и средства за генериране на мигриращи скриптове за данните и промяна на достъпа от програмата. Това описание е същинският код на системата. То трябва да се пази в SCM система и другото да се генерира като част от билда. То трябва да се тества от тестовете.
Други идеи? Конкретни реализации? Едва ли моето "описание" е нещо революционно. По-скоро съм го чел някъде и съм забравил източника
. Подозирам все пак Дейв Хънт и Анди Томас -- the pragmatic programmers.
RealGuru, там дето си ме захапал за дизайна на цялото май не сме се разбрали. Не съм имал предвид физическо "връзване" на базата към програмния език. Идеята ми по-горе може да се разшири към езиково независимо описание и адаптирането на билд процеса към няколко езика. Дали усилията си струват? Ами всички сме виждали извращения като таблици със 200+ колони защото "полета се добавят лесно". Често изискванията се променят или програмата се надгражда. Системата може да бъде много по-гъвкава, проста и евтина ако дизайн решенията ни се водят от бизнес причини и не се спъват от страха да не би да счупим нещо.
--
Екстремно програмиране на български.
[линк]
Re: Agile бази данни... експерименти
Малко пояснения за експеримента ми:
Тъкмо напротив - тестовете вървяха през няколко минути. Тестовите данни не бяха толкова много - цялата сюита вървеше около секунда.
Ами базите бяха с едно име. Просто на дев машината и на сървъра имах "истинска" база и такава, която се създаваше и унищожаваше само за тестовете. sed магиите бяха, за да мога да създам база със същата структура, като истинската, но с различно име. Пак държа да отбележа, че езика на разработка беше PHP, а там "билд" е малко интересно понятие.
Съгласен съм за тестовия сървър. Просто не можах да се организирам дотам, че да си направя такава "инфраструктура". Да кажем, че съм приложил правилото 80/20 или пък, че ме е домързяло.. Ръчните промени бяха за по-интересни промени в базата. Правих ги на ръка донякъде от суеверие и страх. След промяната имах модифицираните скриптове за схемата и изхвърлях миграционните скриптове -- не ми се е налагало да поддържам стари или междинни версии. Модифицираните скриптове за създаването на схемата се тестваха с гореописаната тестова база.
--
Екстремно програмиране на български.
[линк]
В отговор на:Копието се създаваше и инициализираше с данни на всяко изпълнение на тестовете.
Малко излишно, според мен веднъж дневно е достатъчно. Примерно 3 часа посред нощ е едно добро време да се стартират такива тестове. :-))
Тъкмо напротив - тестовете вървяха през няколко минути
. Тестовите данни не бяха толкова много - цялата сюита вървеше около секунда.
В отговор на:Въпреки, че ако при малко по-добро планиране няма смисъл да се променя нищо. Въпросът е логичен. Защо базата ти се казва с едно име на дев. сървъра и с друго на прод. сървъра? И защо трябва да имаш различни неща, които да се променят със sed. Ми изкарай си ги на параметри и като правиш билд, казвай дали е прод. или дев. билд. Потребителя и паролата, разбира се, не трябва да са в скрипта, поради съображения за сигурност.
Ами базите бяха с едно име. Просто на дев машината и на сървъра имах "истинска" база и такава, която се създаваше и унищожаваше само за тестовете. sed магиите бяха, за да мога да създам база със същата структура, като истинската, но с различно име. Пак държа да отбележа, че езика на разработка беше PHP, а там "билд" е малко интересно понятие.
В отговор на:Ако имаше тест сървър (stage) нямаше да те е страх толкова. Щеше да караш по-смело.
И защо трябва да правиш неща на ръка. Това е гаден навик. На ръка трябва да се логваш само и да викаш главния скрипт. Иначе може да изтървеш нещо и после 2 седмици да се чудиш що не работи.
Съгласен съм за тестовия сървър. Просто не можах да се организирам дотам, че да си направя такава "инфраструктура". Да кажем, че съм приложил правилото 80/20 или пък, че ме е домързяло.
. Ръчните промени бяха за по-интересни промени в базата. Правих ги на ръка донякъде от суеверие и страх. След промяната имах модифицираните скриптове за схемата и изхвърлях миграционните скриптове -- не ми се е налагало да поддържам стари или междинни версии. Модифицираните скриптове за създаването на схемата се тестваха с гореописаната тестова база.--
Екстремно програмиране на български.
[линк]
Re: Рефакторинг на БД
рефакторинг - ок
обаче как според тебе се прави такова нещо на 1Г база работеща при клиенти
и опитвал ли си да убедиш големите шефове за такова нещо?
"дайте да им спреме базата за около 2 седмици клиентите че си починат а ние през това време че си оправяме лайната, като сваршиме ако сичо успее да трагне клиентите че са супер доволни"
иначе ас сам за за сичките хубави неща
обаче как според тебе се прави такова нещо на 1Г база работеща при клиенти
и опитвал ли си да убедиш големите шефове за такова нещо?
"дайте да им спреме базата за около 2 седмици клиентите че си починат а ние през това време че си оправяме лайната, като сваршиме ако сичо успее да трагне клиентите че са супер доволни"
иначе ас сам за за сичките хубави неща
Re: Рефакторинг на БД
Как да елиминираме дупликацията? Не знам! Напоследък ми се върти из главата някаква възможност за описване на структурата на данните с някакъв специфичен език. Няма значение дали ще е скриптов език, SQL, XML Schema, DTD, C++ или C# код. Важното е от него да мога да генерирам схемата на базата и механизма за достъп до данните от програмата. Трябва да имам и средства за генериране на мигриращи скриптове за данните и промяна на достъпа от програмата. Това описание е същинският код на системата. То трябва да се пази в SCM система и другото да се генерира като част от билда. То трябва да се тества от тестовете.
То има доста такива инструменти. Даже в спецификацията на UML го вкараха. За Java и техните идеи за persistent object, jdo, бла-бла даже има няколко с отворен код. Описваш си схемата в XML и от там се генерира БД, даже като бонус получваш генериран код на класовете. :-)
Ами всички сме виждали извращения като таблици със 200+ колони защото "полета се добавят лесно". Често изискванията се променят или програмата се надгражда. Системата може да бъде много по-гъвкава, проста и евтина ако дизайн решенията ни се водят от бизнес причини и не се спъват от страха да не би да счупим нещо.
200 полета в една таблица не трябва да е проблем, ако мястото им е там. Ако имат връзка 1:1 към ключа на таблицата, според правилата на нормализацията трябва да са там. Много повече трябва да се плашиш от схема, която не е нормализирана.
Разбира се, че изискванията към една програма се променят доста бързо. Но обикновено, това не засяга много БД. Има много начини да направиш GUI-то, примерно за въвеждане на фактура. Обаче, опитималния (нормалния) начин да представиш фактурата в БД е само един. В началото може да не помислиш за начина на плащане и в последствие да добавиш ново поле за тази операция. Но това не трябва да е проблем, защото то не указва влияние над другите данни. Или друг пример. Сега е модерно да се продава на кредит. Съответно към фактурата може да добавиш и условията на кредита и кога какво е платено. В този случай трябва да добавяш таблици, а не полета, но това пак не изменя текущата схема. Т.е. не трябва да променяш наличната схема за фактурата. Точно това е цялата на идея на нормализацията.
В интерес на истината и с програмата и GUI-то трябва да е така.
То има доста такива инструменти. Даже в спецификацията на UML го вкараха. За Java и техните идеи за persistent object, jdo, бла-бла даже има няколко с отворен код. Описваш си схемата в XML и от там се генерира БД, даже като бонус получваш генериран код на класовете. :-)
Ами всички сме виждали извращения като таблици със 200+ колони защото "полета се добавят лесно". Често изискванията се променят или програмата се надгражда. Системата може да бъде много по-гъвкава, проста и евтина ако дизайн решенията ни се водят от бизнес причини и не се спъват от страха да не би да счупим нещо.
200 полета в една таблица не трябва да е проблем, ако мястото им е там. Ако имат връзка 1:1 към ключа на таблицата, според правилата на нормализацията трябва да са там. Много повече трябва да се плашиш от схема, която не е нормализирана.
Разбира се, че изискванията към една програма се променят доста бързо. Но обикновено, това не засяга много БД. Има много начини да направиш GUI-то, примерно за въвеждане на фактура. Обаче, опитималния (нормалния) начин да представиш фактурата в БД е само един. В началото може да не помислиш за начина на плащане и в последствие да добавиш ново поле за тази операция. Но това не трябва да е проблем, защото то не указва влияние над другите данни. Или друг пример. Сега е модерно да се продава на кредит. Съответно към фактурата може да добавиш и условията на кредита и кога какво е платено. В този случай трябва да добавяш таблици, а не полета, но това пак не изменя текущата схема. Т.е. не трябва да променяш наличната схема за фактурата. Точно това е цялата на идея на нормализацията.
В интерес на истината и с програмата и GUI-то трябва да е така.
Re: Рефакторинг на БД
И аз това викам.
Рефакторинг на кода може да правиш по-лесно. Когато клиента иска нови неща, спокойно може да рефакторираш и старите, ако не те мързи. :-)
Обаче, ако трябва да рефакторираш БД, става каша. Пък и клиентите рядко искат. Аз преди 1-2 години имах интересен случай. Клинетът се опъваше (не че аз горях от желание), ама нямаше какво друго да се направи.
Почти накрая на гаранционния срок няква функционалност спира да работи. Дава таймаут. И се почват едни разследвания и пр. неприятни истории как това е възможно. На всичкото отгоре системата е тествана с 3 милиона данни, които отговарят на 5 год. използване. И въпросното чудо не е било хванато там. А само след 1 година на използване с 0.5 милиона данни това спира. Пък кво остава за понататък. Както и да е беше доста голям скандал. :-)))
А въпросната фукнционалност е няква мижава, за нея няма изчисления колко данни ще има. Лесно се реализира, нищо сложно няма и трябва да работи като пушка. Там където са тествали в таблицата има 5 записа на кръст, а в лайв системата има над 50 000 записа в съответната таблица. Баси нищо работа на пръв поглед.
Значи имаш главен обект. Към него можеш да закачаш 15 различни неща. Едно от тях е нашто. Типична релация 1:М. И супер елементарно няма търсене, само трябва да ги изкараш по ИД на главния обект. И естествено има добавяне, редактиране и изтриване на тези под елементчета.
Значи таблицата:
1. ID_master_object - foreign key, reference to master object
2. Pos - int check(1 <= Pos and Pos <= 3)
3. ID_element - foreign key, reference to element table
4. Count - int
Uniq constraint ID_master_object, Pos, ID_element
Значи имаш позиция (от 1 до 3) на всяка позиция може да има различен елемент и съответно бройка. Като на една позиция не може да имаш два еднакви елемента (логично). За списъка на елементите имаш друга таблица от около 200 елемента.
Заявката изглежда така:
Select Element.ID, Element.Name, Table.Count, Table.Pos
From Table, Element
Where ID_master_object = X and Table.ID_element = Element.ID
Това е "нормалното" положение. Така изглеждаше таблицата след нормализацията. А преди това, беше върха на сладоледа. Някой велик мастер оф програминг се беше изхвърлил по темата. Човекът се хванал за това, че има три заковани позиции и направил следното.
1. ID - autoincrement
2. ID_master_object - foreign key, reference to master object
3. Pos1 - nullable, foreign key, reference to element table
4. Pos2 - nullable, foreign key, reference to element table
5. Pos3 - nullable, foreign key, reference to element table
6. Count - int
Check constaint (Pos1 = null and Pos2 = null and Pos3 != null) or
(Pos1 = null and Pos2 =! null and Pos3 = null) or
(Pos1 != null and Pos2 = null and Pos3 = null)
Естествено липсва проверка за уникалност, тя е в кода. :-)
А заявката излежда така.
Select Element.ID, Element.Name, Table.Count, Table.Pos
From Table, Element
Where ID_master_object = X and
Table.Pos1 (+)= Element.ID and
Table.Pos2 (+)= Element.ID and
Table.Pos3 (+)= Element.ID
Има 3 Outher Join-а срещу един Inner Join в другия случаи. Оракъла се моташе над 5 мин на втората заявка, срещу някви милисекунди на първата. А ставаше въпрос за около 200 елемента и около 10 000 главни обекта, средно с по пет записа - общо 50 000 записа в злощастната таблица. Естествено това беше уеб приложение и браузърите умират като нямат отговор 2 мин.
Ама на нормализация му е майката. Ако мастера беше чел малко нормализация, щеше да знае, че така се прави. :-)
Ама те и другите са за е..., щото никой не е го е тествал сериозно на 5 год. база.
Рефакторинг на кода може да правиш по-лесно. Когато клиента иска нови неща, спокойно може да рефакторираш и старите, ако не те мързи. :-)
Обаче, ако трябва да рефакторираш БД, става каша. Пък и клиентите рядко искат. Аз преди 1-2 години имах интересен случай. Клинетът се опъваше (не че аз горях от желание), ама нямаше какво друго да се направи.
Почти накрая на гаранционния срок няква функционалност спира да работи. Дава таймаут. И се почват едни разследвания и пр. неприятни истории как това е възможно. На всичкото отгоре системата е тествана с 3 милиона данни, които отговарят на 5 год. използване. И въпросното чудо не е било хванато там. А само след 1 година на използване с 0.5 милиона данни това спира. Пък кво остава за понататък. Както и да е беше доста голям скандал. :-)))
А въпросната фукнционалност е няква мижава, за нея няма изчисления колко данни ще има. Лесно се реализира, нищо сложно няма и трябва да работи като пушка. Там където са тествали в таблицата има 5 записа на кръст, а в лайв системата има над 50 000 записа в съответната таблица. Баси нищо работа на пръв поглед.
Значи имаш главен обект. Към него можеш да закачаш 15 различни неща. Едно от тях е нашто. Типична релация 1:М. И супер елементарно няма търсене, само трябва да ги изкараш по ИД на главния обект. И естествено има добавяне, редактиране и изтриване на тези под елементчета.
Значи таблицата:
1. ID_master_object - foreign key, reference to master object
2. Pos - int check(1 <= Pos and Pos <= 3)
3. ID_element - foreign key, reference to element table
4. Count - int
Uniq constraint ID_master_object, Pos, ID_element
Значи имаш позиция (от 1 до 3) на всяка позиция може да има различен елемент и съответно бройка. Като на една позиция не може да имаш два еднакви елемента (логично). За списъка на елементите имаш друга таблица от около 200 елемента.
Заявката изглежда така:
Select Element.ID, Element.Name, Table.Count, Table.Pos
From Table, Element
Where ID_master_object = X and Table.ID_element = Element.ID
Това е "нормалното" положение. Така изглеждаше таблицата след нормализацията. А преди това, беше върха на сладоледа. Някой велик мастер оф програминг се беше изхвърлил по темата. Човекът се хванал за това, че има три заковани позиции и направил следното.
1. ID - autoincrement
2. ID_master_object - foreign key, reference to master object
3. Pos1 - nullable, foreign key, reference to element table
4. Pos2 - nullable, foreign key, reference to element table
5. Pos3 - nullable, foreign key, reference to element table
6. Count - int
Check constaint (Pos1 = null and Pos2 = null and Pos3 != null) or
(Pos1 = null and Pos2 =! null and Pos3 = null) or
(Pos1 != null and Pos2 = null and Pos3 = null)
Естествено липсва проверка за уникалност, тя е в кода. :-)
А заявката излежда така.
Select Element.ID, Element.Name, Table.Count, Table.Pos
From Table, Element
Where ID_master_object = X and
Table.Pos1 (+)= Element.ID and
Table.Pos2 (+)= Element.ID and
Table.Pos3 (+)= Element.ID
Има 3 Outher Join-а срещу един Inner Join в другия случаи. Оракъла се моташе над 5 мин на втората заявка, срещу някви милисекунди на първата. А ставаше въпрос за около 200 елемента и около 10 000 главни обекта, средно с по пет записа - общо 50 000 записа в злощастната таблица. Естествено това беше уеб приложение и браузърите умират като нямат отговор 2 мин.
Ама на нормализация му е майката. Ако мастера беше чел малко нормализация, щеше да знае, че така се прави. :-)
Ама те и другите са за е..., щото никой не е го е тествал сериозно на 5 год. база.
Re: Рефакторинг на БД
И ти и Крум се водите от страха. Как да променя ХХХ гигабайтовата база без да счупя нещо??? А как ще разбера дали съм го счупил? А как знам какво трябва да прави системата, че да разбера дали го прави и не го прави в резултат от моите промени? А как да знам, че преди си е вършила работата и точно моите промени от днес са я счупили?
Моята тИория е, че система и схема на базата еволюирани с поддържащите рефакторинга практики няма да са зависими от тези страхове. Колко струват тези практики? Ами няколко "топ" човека и малко време в началото с много спестено време в средата и края. С RAD програмисти дето знаят само как се databind-ва някой грид контрол, това обаче не го виждам да стане.
За ГУИ-то съм съгласен. Дупликацията си е дупликация. Наличието й е симптом за липса на архитектура и абстракция.
Искам само да питам във връзка с анекдота за майстора на програмирането: тоя човек, за да избере такова решение явно не е знаел, че приложението трябва да се справя с много данни в тази си част нали? Хм май пак влизаме в графата допълнителни практики.
Абе изобщо май се опитваш да ми кажеш, че не можем да рефакторваме кода без тестове, а пък базата не можем да я рефакторваме щото нямаме тестове.
--
Екстремно програмиране на български.
[линк]
. Как да променя ХХХ гигабайтовата база без да счупя нещо??? А как ще разбера дали съм го счупил? А как знам какво трябва да прави системата, че да разбера дали го прави и не го прави в резултат от моите промени? А как да знам, че преди си е вършила работата и точно моите промени от днес са я счупили?
Моята тИория е, че система и схема на базата еволюирани с поддържащите рефакторинга практики няма да са зависими от тези страхове. Колко струват тези практики? Ами няколко "топ" човека и малко време в началото с много спестено време в средата и края. С RAD програмисти дето знаят само как се databind-ва някой грид контрол, това обаче не го виждам да стане.
За ГУИ-то съм съгласен. Дупликацията си е дупликация. Наличието й е симптом за липса на архитектура и абстракция.
Искам само да питам във връзка с анекдота за майстора на програмирането: тоя човек, за да избере такова решение явно не е знаел, че приложението трябва да се справя с много данни в тази си част нали? Хм май пак влизаме в графата допълнителни практики.
Абе изобщо май се опитваш да ми кажеш, че не можем да рефакторваме кода без тестове, а пък базата не можем да я рефакторваме щото нямаме тестове.
--
Екстремно програмиране на български.
[линк]
Re: Рефакторинг на БД
И ти и Крум се водите от страха
именно защото ако нещата се насерат тряба някой да поеме отговорност (на клиента му е се тая що е счупено той казва вчера си бачкаше а са след рефакторинга неще, начи вие сте го счупили)
безумно е да мислиш че можеш сас тестове да изчистиш баговете на 100%
проблема сас баг вав робетеща база е че ако блокираш работата на 200 лелки и те цял ден место да си варшат работата си барат ташаците отговорността която трябва да поемеш е ОГРОМНА
представи си какво става ако пак на твоя глава (без да е сагласувано сас клиента) сложиш нещо което им счупи базата, чувал си за садебни искове нали
от друга страна малко ми е трудно да си представя как ще убедиш клиент да му бараш по работещата(а дали работи вобще?) база само за да си направиш рефакторинга.
а пък базата не можем да я рефакторваме щото нямаме тестове.
отнова да
нещо работещо вав грозниа си вариант вече 8-9 години е абсурдно да се тества
говориме за няколко милиона реда + н на брой крапки за да се поддаржа динозавара жив
не казвам че това е добро, нито ас сам ас човека от когото зависат нещата
но честно казано разбирам защо хората от които зависи не се наемат сас такова нещо
именно защото ако нещата се насерат тряба някой да поеме отговорност (на клиента му е се тая що е счупено той казва вчера си бачкаше а са след рефакторинга неще, начи вие сте го счупили)
безумно е да мислиш че можеш сас тестове да изчистиш баговете на 100%
проблема сас баг вав робетеща база е че ако блокираш работата на 200 лелки и те цял ден место да си варшат работата си барат ташаците отговорността която трябва да поемеш е ОГРОМНА
представи си какво става ако пак на твоя глава (без да е сагласувано сас клиента) сложиш нещо което им счупи базата, чувал си за садебни искове нали
от друга страна малко ми е трудно да си представя как ще убедиш клиент да му бараш по работещата(а дали работи вобще?) база само за да си направиш рефакторинга.
а пък базата не можем да я рефакторваме щото нямаме тестове.
отнова да
нещо работещо вав грозниа си вариант вече 8-9 години е абсурдно да се тества
говориме за няколко милиона реда + н на брой крапки за да се поддаржа динозавара жив
не казвам че това е добро, нито ас сам ас човека от когото зависат нещата
но честно казано разбирам защо хората от които зависи не се наемат сас такова нещо