Розміщення рівня доступу до даних

Ситуація: dba - це підрядний підрядник, який зберігає весь DAL-код, перевірений у TFS. Було б непогано, як розробник переднього кінця мати можливість додавати стовпці, налаштовувати документи та інше, не сподіваючись на очікування, коли цей чувак відповість на ваші електронні листи, щоб виконати роботу.

Запитання: Що було б рекомендованим рішенням / процесом, який би дозволяв швидше / спритний розвиток, зберігаючи цілісність даних, а також миролюбність і щастя серед команди?

Мартін Фаулер та Прамод Садладж написали чудову статтю на цю тему.

У кожного розробника є своя база даних, в яку можуть бути внесені зміни. Ці зміни потім передаються назад (як набір змін) до DBA, який реалізує їх у головній базі даних, тому він все ще бере участь у процесі, він, мабуть, найкраще знає про структури та потреби бази даних у будь-якому разі. Я думаю, що це найкращий підхід, оскільки він задовільний для всіх людей, які беруть участь у процесі, а також він дуже спритний.

Ви можете змінити DAL аналогічним чином. Просто внесіть зміни та надайте набір змін для DBA, коли ви думаєте, що ви закінчили, щоб він міг переглянути його та об'єднати його зі своїм господарем.

Ну, коли я роблю справу з DBA, мені було відомо, що я все закриваю, щоб чортові брудні програмісти не змогли домогтися їх. Всі думають, що вони знають, як це зробити краще, і вони «підправляють» речі, щоб полегшити їх собі, і це спричиняє нечесний безлад.

Інша альтернатива - кинути його широко відкритим, і дозволити програмістам блискавити по ньому деякий час, а потім заскочити і навести порядок, коли все починає накручуватися ... Це, безумовно, "спритніше", але це може бути справжній кошмар залежно від того, що треба вирізати чи змінити ... Асоціація оборонців часто краще розуміє проект у цілому, а деякі зміни, які здаються нешкідливими, можуть бути проблематичними.

Якщо він буде єдиним воротарем, йому потрібно або мати фіксовану специфікацію, або бути в змозі "продати" своє бачення решті бісів.

Існує головна проблема, яка перевершує будь-яку іншу проблему:

1. Чому підрядник завжди перевіряє код?

Чому йому дозволено це робити? Ніхто не повинен перевіряти файл, якщо вони активно не вносять зміни. Повинна бути командна політика щодо оформлення замовлень.

Підрядник (їм це подобається чи ні) працює в складі команди, а іноді іншим членам команди може знадобитися внести зміни. Це питання зв’язку. На жаль, немає автоматизованого способу вирішити цю проблему зв'язку.

Замість горизонтальних шарів я вважаю за краще працювати в силосах поперек шарів.

Таким чином жодна людина / команда не може блокувати таким чином.

Це також означає, що ви розробники багатокваліфіковані і здатні набагато легше переміщувати функції.

Звичайно, є розділи (дизайн інтерфейсу та дизайн баз даних), які можуть потребувати більш спеціалізованих робіт, але ви розумієте.

Просто, якщо ви ще цього не зробили, у вас повинні бути 3 середовища:

• Середовище розвитку
• Навколишнє середовище QA
• Виробниче середовище

Середовище розробки має адмініструвати ваші розробники.

Ви також можете додати середовище RC.

Ще одна відповідь: Якщо декілька середовищ неможливі, ви можете розробитись із насмішкуваного сховища ... Таким чином ви будуєте свої моделі, а потім ваш підрядник відповідає за те, щоб ваші моделі відповідали БД. Зрештою, це краще, оскільки це звільняє ваших розробників від турботи про базу даних.

У вас проблема, здається, є однією з робочих сил. Це доцільно і необхідно, щоб усі можливі зміни бази даних були затверджені фахівцем з бази даних. Якщо нинішня людина не може вчасно не відставати від роботи, вам потрібно більше фахівців із бази даних.

Це питання управління як настільки технічне.

Безумовно, є вагомі причини для DBA (незалежно від того, на місці чи виходу, підрядника чи працівника), щоб уникнути розробників від внесення будь-яких змін у базу даних.

Однак головна проблема, яку ви визначили, - це наявність. Чи знає ваш менеджер, що на цю людину витрачається витрачений час / гроші? Якщо ні, то, можливо, ви захочете вияснити, як усі сидять.