Советы по разработке веб-приложения со сроком службы более 40 лет

73

сценарий

В настоящее время я занимаюсь проектом здравоохранения, основным требованием которого является сбор данных с неизвестными атрибутами с использованием пользовательских форм, предоставляемых поставщиками медицинских услуг. Второе требование заключается в том, что целостность данных является ключевой и что приложение будет использоваться более 40 лет. В настоящее время мы переносим данные клиента за последние 40 лет из различных источников (Paper, Excel, Access и т. Д.) В базу данных. Будущие требования:

  • Управление рабочим процессом форм
  • Расписание управления формами
  • Безопасность / Ролевое управление
  • Механизм отчетности
  • Поддержка мобильных устройств / планшетов

ситуация

Всего через 6 месяцев нынешний (по контракту) архитектор / старший программист принял «быстрый» подход и разработал плохую систему. База данных не нормализована, код связан, уровни не имеют специального назначения, и данные начинают пропадать, так как он разработал некоторые bean-компоненты для «удаления» базы данных. Кодовая база чрезвычайно раздутая, и есть задания только для синхронизации данных, поскольку база данных не нормализована. Его подход заключался в том, чтобы полагаться на задания резервного копирования для восстановления недостающих данных, и, похоже, не верит в рефакторинг.

Представив мои выводы в личку, архитектор будет удален, когда закончится его контракт. Мне было дано задание перепроектировать это приложение. Моя команда состоит из меня и одного младшего программиста. У нас нет других ресурсов. Нам было предоставлено право на 6-месячное замораживание требований, в рамках которого мы можем сосредоточиться на перестройке этой системы.

Я предложил использовать систему CMS, такую ​​как Drupal, но по соображениям политики в организации клиента, система должна быть построена с нуля.

Впервые я буду проектировать систему с продолжительностью жизни более 40 лет. Я работал только над проектами с продолжительностью жизни 3-5 лет, так что эта ситуация очень новая, но захватывающая.

Вопросов

  • Какие конструктивные особенности сделают систему более «ориентированной на будущее»?
  • Какие вопросы следует задать клиенту / руководителю, чтобы сделать систему более «ориентированной на будущее»?
Пит
источник
59
Проверка будущего - это одно, но я считаю, что клиент должен запросить программное обеспечение с ожидаемым сроком службы, который в 10–20 раз больше, чем текущая история мобильных / планшетных компьютеров, или в 5– 8 раз больше, чем текущая история языка. используется ... неоправданно оптимистично по поводу стабильности данной модели вычислений.
31
проектирование, чтобы быть 40-летним «будущим» звучит как бесполезное упражнение.
whatsisname
10
Чтобы выполнить требование о том, чтобы база данных была полезной в течение следующих 40 лет, я поместил бы все это на бумаге. Бумага зарекомендовала себя, в то время как цифровое хранилище доказало, как быстро потерять много данных. (но, конечно же, сохраните все данные, которые должны быть уничтожены)
Питер B
34
Они дают двум контрактным разработчикам 6 месяцев на создание этой системы? Сбор многолетних данных И предвидение новых требований десятилетия в будущее? Если вы еще не уходите от проекта, начните работать. Это намного больше, чем два человека могут справиться с чем-либо, близким к установленным временным рамкам. У клиента совершенно необоснованные ожидания и он не желает выделять необходимые ресурсы для проекта.
Шон МакSomething
12
6 месяцев для 2 человек, чтобы разработать и внедрить приложение, которое должно длиться более 40 лет? Не имеет значения, насколько вы хороши, это звучит как установка на неудачу. Если вы не можете убедить свою организацию, насколько это необоснованно, я бы посоветовал вам начать искать другую работу как можно скорее.
dsw88

Ответы:

132

Данные король

Я думаю, что было бы немного неразумно ожидать, что веб-приложение к 2013 году будет работать и работать в 2053 году. Технологии изменятся. Платформы будут приходить и уходить. HTML может быть странным воспоминанием к тому времени. Но ваши данные все еще будут рядом.

Таким образом, данные - ваш главный фокус. Пока ваши данные все еще там, люди смогут адаптироваться к любым новым технологиям. Убедитесь, что ваши схемы данных хорошо продуманы и хорошо подходят для расширения. Не торопитесь, уточняя их.

Что касается реальных применений, ваша компания, вероятно, здесь правильно использует директиву «с нуля». Я поддерживаю пару веб-приложений старше 10 лет, и я очень рад, что они не привязаны к преобладающим системам CMS 2003 года. Они используют очень простые домашние фреймворки. Я думаю, что для чего-то подобного вам лучше использовать базовую структуру, которую вы создаете специально для нужд проекта.

Но реальность такова, что через 40 лет компания (надеюсь) будет предлагать немало фронт-эндов и бэк-эндов для адаптации к развивающимся платформам. Исходя из этого, я бы рассчитал на 5-10 лет жизни для отдельных пользовательских приложений.

GrandmasterB
источник
13
"мы не сможем использовать этот код через 40 лет!" Вот почему была ошибка Y2K для начала. Ожидать замены вашего кода - это просто плохая практика.
DougM
71
«Ошибка» 2000 года была проблемой с данными - хранились 2 цифры вместо 4. Вот почему я предлагаю сосредоточиться на данных.
GrandmasterB
24
Хорошая точка зрения. Помня об этом, если кто-то действительно ожидает, что его данные (и, возможно, база данных) будут использоваться через 40 с лишним лет, может быть лучше спроектировать базу данных с как можно меньшим количеством специфических для поставщика функций. Тот, кто должен распутать / переписать весь ваш код, который использует специальные Oracle / MS-SQL / любую функциональность через 20 лет, не будет счастлив с вами. ;)
FrustratedWithFormsDesigner
4
Это твердый совет. До сих пор запущено множество программ на Cobol, которые были написаны 20-30 лет назад. Хотя технология продолжает развиваться, если ваши данные и объектная модель надежны и данные по-прежнему представляют интерес, ваш код в той или иной форме будет использоваться.
Bobble
7
Поскольку кто-то поднял Y2K: помните о UNIX Y2K ( en.wikipedia.org/wiki/Year_2038_problem ).
MrFox
40

Мы производим программное обеспечение, которое используется для оплаты клиентов более 20 лет. Кодовая база пережила несколько поколений инструментов контроля версий. Наше программное обеспечение поражает все ваши точки, кроме планшета.

Некоторые из проблем включают ESIGN и UETA . Наши юристы считают, что нам нужно, чтобы электронные записи читались в течение как минимум 10 лет. Для документов, которые сохраняются целиком, вы должны смотреть в PDF / A .

Для вашей базы данных не слишком беспокоитесь о нормализации. Вместо этого вы должны заботиться о регистрации всего и иметь таблицы аудита, которые отслеживают изменения / удаления в данных. При обновлении версий планируйте параллельное тестирование новых версий в течение достаточного времени, чтобы убедиться, что ваши данные перенесены. Это тестирование новых версий также включает новые операционные системы - за эти годы у нас было несколько неприятных сюрпризов. Сохраните установочный носитель и лицензионные ключи на случай необходимости отката. Тестовые резервные копии. Если вы собираетесь сериализовать объекты для хранения в базе данных, делайте это в виде XML вместо сериализации, предоставляемой вашей средой разработки.

Для вашего персонала долгосрочные базы кода нуждаются в долговременной памяти. В идеале вы хотели бы, чтобы люди вокруг были вокруг. Если это невозможно с организационной точки зрения, то вам нужно документировать все в чем-то вроде вики. И мой совет - это вики, которая может быть связана с вашей системой отслеживания ошибок.

Для вашей кодовой базы, убедитесь, что у вас есть комментарии в вашем коде. Миграция с одной системы контроля версий на другую почти всегда приводит к потере комментариев о регистрации. Я фанат именования юнит-тестов после спецификаций и номеров ошибок. Таким образом, если модульное тестирование будет Test_Bug_1235 прервано, вы будете знать, что и где отслеживать, что предполагается тестировать. Это не так «сексуально», как называть ваши тесты, Check_File_Save_Networked_Drivesно в отличие от этого теста трудно отследить спецификации, требования или ошибки Test_requirement_54321_case_2.

Tangurena
источник
Спасибо, что поделились своим опытом. Я определенно нуждаюсь в некоторых из них, поскольку нынешний архитектор не прокомментировал ни один из его кодов и не предоставил нам никакой документации. Это был логистический кошмар, но я надеюсь изменить это. PDF / A - это то, что я обязательно изучу, так как это то, что понадобится нашему клиенту - особенно для аудита. Еще раз спасибо за ваш совет!
Пит
4
Это исчерпывающий и продуманный ответ. Вы подчеркиваете важность аудита как для изменения данных и качества данных, так и для юридических целей отслеживания того, кто какие данные просматривает, см. HIPAA . Если ваше программное обеспечение будет использоваться в Соединенных Штатах, то у вас будут определенные ограничения безопасности и требования, требуемые в соответствии с этим законом.
maple_shaft
3
… По крайней мере SVN для git возможен с полной историей коммитов.
feeela
Не только SVN to Git, но и большинство систем не каменного века, хотя старые, такие как CVS, часто нуждаются в ручной настройке с помощью reposurgeon. Большинство экспортеров также генерируют поток git-fast-export, который достаточно прост, чтобы его можно было импортировать и в не-Git VCS.
grawity
2
Я предлагаю вам не называть Тесты только после номеров отслеживания ошибок и спецификаций, так как: а) номера ошибок начинаются с 0 (так как никому не нравится> 5-значные номера и программное обеспечение для отслеживания ошибок заменяется; б) спецификации имеют тенденцию заблудиться (некрасиво, но бывает достаточно часто); в) Сексуальные имена часто дают понять достаточно. Хотя наличие ссылки на спецификацию / идентификатор ошибки всегда является хорошей идеей.
Бернштейн
29

Вместо того, чтобы пытаться выяснить, как это приложение будет продолжать работать через 20 лет, я думаю, вам следует потратить шесть месяцев на решение проблем, которые вы обнаружили в первоначальном архитекторе, создать разумную, надежную архитектуру и двигаться вперед оттуда.

Частичная ненормализация базы данных не обязательно является совершенно неожиданной в медицинских условиях. Некоторые части медицинских баз данных имеют характеристики, которые делают их подходящими для модели EAV (Entity / Attribute / Value) .

Роберт Харви
источник
2
@ user2708395 Будьте осторожны с дизайном EAV, так как он может быть не самым производительным или простым в запросе. Это также не может быть хорошим выбором для отчетности.
maple_shaft
@maple_shaft Я тоже это читал. Я собираюсь быть очень осторожным с этим, поскольку я услышал некоторые ужасные истории, где люди злоупотребляют этим. Рассматривая использование некоторой базы данных отчетов, чтобы упростить запрос, так как клиент генерирует отчеты только один раз в месяц.
Пит
4
@maple_shaft: Обычно данные извлекаются из схемы / базы данных EAV в отдельную схему / базу данных отчетов.
FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner Это отличный момент. Гибкость вашей схемы, которую обеспечивает EAV, не имеет себе равных, но она, безусловно, не является серебряной пулей для всей настойчивости.
maple_shaft
Хотя я позволю вам использовать EAV, вы будете удивлены тем, какие отношения вы сможете найти. Тем не менее, дополнительные атрибуты, которые часто обнаруживаются для таких отраслей (здравоохранение, отношения с клиентами и т. Д.), Действительно должны куда-то идти ... Просто убедитесь, что они подкреплены таблицей атрибут-ключ, чтобы получить канонический список атрибутов.
Заводная муза
13

Ответ с точки зрения внешнего интерфейса:

Не слушайте, чтобы все говорили, что это невозможно, потому что экспериментальный веб-сервис Государственного университета Сан-Франциско, который я в соавторстве написал в 1996 году, наконец-то попал в Интернет-рай пару лет назад и в то время не требовалось ни одного исправления совместимости браузера. ; это почти половина вашей 40-летней цели. И этот интерфейс на основе JavaScript, который я сделал в 1998 году для проекта Стэнфордского исследовательского института, несколько лет спустя был заменен чем-то более ярким, но нет никаких причин, по которым оригинальный пользовательский интерфейс все еще не мог работать сегодня с небольшими исправлениями совместимости.

Хитрость заключается в том, чтобы убедиться, что ваше приложение использует только широко поддерживаемые стандарты W3C / ECMA и имеет чистый дизайн под вашим контролем. Хотя многие веб-приложения, написанные по модной технологии эпохи 90-х, не будут работать должным образом или вообще не работают сегодня, веб-приложения эпохи 90-х, написанные в соответствии с основными стандартами, по-прежнему работают. Они могут выглядеть пассивно, но они работают.

Цель здесь не в том, чтобы написать веб-приложение, которое будет работать на своем сервере и оставаться там в течение 40 лет, и никто не будет к нему прикасаться. Это создание основы, которая может использоваться десятилетиями, которая может расширяться для поддержки новых функций без необходимости восстановления с нуля.

Прежде всего, вы должны соблюдать официальные стандарты и только официальные стандарты. Нет функций JavaScript, не являющихся частью ратифицированного стандарта ECMAScript; ES5.1 является текущей версией и обычно поддерживается, так что это безопасно для цели. Аналогично, текущие версии HTML5, CSS и Unicode хороши. Нет экспериментальных функций JavaScript, CSS3 или HTML (с префиксами поставщиков или без 100% согласия между браузерами). И никаких браузерно-совместимых взломов совместимости. Вы можете начать использовать новую функцию, как только она появится в стандарте, и все поддерживают ее без префиксов.

Поддержка ES5 будет означать отказ от IE8 или более ранней версии, что я предлагаю в любом случае, так как для этого требуются взломы для конкретных браузеров, которые через пару лет будут бесполезны. Я бы посоветовал строгий режим ES5 для лучшего шанса на долголетие, который фактически устанавливает совместимость вашего базового браузера с IE10 и последними версиями всех остальных . Эти браузеры также имеют встроенную поддержку многих функций проверки формы HTML5 и заполнителей, которые будут полезны в течение очень долгого времени.

Новые выпуски ECMAScript поддерживают совместимость с более старыми версиями, так что будет гораздо проще принять новые функции, если ваш код написан в соответствии с текущими стандартами. Например, классы, определенные с использованием следующего classсинтаксиса, будут полностью взаимозаменяемы с классами, определенными с текущим constructor.prototypeсинтаксисом. Таким образом, через пять лет разработчик может переписывать классы в формат ES6 для каждого файла, не ломая ничего - при условии, конечно, что у вас также есть хорошие модульные тесты.

Во-вторых, избегайте модных фреймворков приложений JavaScript, особенно если они меняют способ кодирования вашего приложения. Backbone был в моде, тогда как SproutCore и Ember, а теперь Angular - это фреймворк, который все любят продвигать. Они могут быть полезны, но у них также есть что-то общее: они часто ломают приложения и требуют изменения кода, когда выходят новые версии и их долговечность сомнительна. Я недавно обновил приложение Angular 1.1 до 1.2, и пришлось немного переписать. Аналогично, переход с Backbone 2 на 3 требует большого количества изменений HTML. Стандарты медленно движутся по какой-то причине, но эти структуры движутся быстро, и периодические сбои являются издержками.

Кроме того, новые официальные стандарты часто оставляют старые фреймворки устаревшими, и когда это происходит, эти фреймворки либо мутируют (с серьезными изменениями), либо остаются позади. Вы знаете, что произойдет со всеми конкурирующими библиотеками обещаний в мире, когда ECMAScript 6 будет ратифицирован, и все браузеры будут поддерживать его стандартизированный класс Promise? Они устаревают, а их разработчики перестанут их обновлять. Если вы выбрали правильный фреймворк, ваш код может адаптироваться достаточно хорошо, и если вы догадались плохо, вы будете рассматривать основной рефакторинг.

Поэтому, если вы думаете о переходе на стороннюю библиотеку или фреймворк, спросите себя, как трудно будет удалить ее в будущем. Если это такая среда, как Angular, которую невозможно удалить без перестройки приложения с нуля, это хороший знак, что ее нельзя использовать в 40-летней архитектуре. Если это сторонний виджет календаря, который вы абстрагировали с помощью некоторого пользовательского промежуточного программного обеспечения, его замена может занять несколько часов.

В-третьих, создайте хорошую, чистую структуру приложения. Даже если вы не используете каркас приложения, вы все равно можете воспользоваться инструментами разработчика, сценариями сборки и хорошим чистым дизайном. Я лично поклонник управления зависимостями Closure Toolkit, потому что он легкий и его издержки полностью удаляются при создании приложения. LessCSS и SCSS также являются отличными инструментами для организации ваших таблиц стилей и создания основанных на стандартах таблиц стилей CSS для выпуска.

Вы также можете организовать свой собственный код в одноразовые классы со структурой MVC. Это значительно облегчит возвращение на несколько лет в будущее и понимание того, о чем вы думали, когда писали что-то, и замену только тех частей, которые в этом нуждаются.

Вы также должны следовать советам W3C и полностью исключить презентационную информацию из своего HTML. (Это включает в себя читы, такие как присвоение имен элементам презентационных классов, таких как «большой зеленый текст» и «два столбца в ширину».) Если ваш HTML является семантическим, а CSS - презентационным, его будет намного проще поддерживать и адаптировать. на новые платформы в будущем. Также будет проще добавить поддержку специализированных браузеров для слепых или инвалидов.

В-четвертых, автоматизируйте свои тесты и убедитесь, что у вас почти полный охват. Напишите модульные тесты для каждого класса, будь то на стороне сервера или в JavaScript. На внешнем интерфейсе убедитесь, что каждый класс работает в соответствии с его спецификацией в каждом поддерживаемом браузере. Автоматизируйте эти тесты от своего сборочного бота для каждого коммита. Это важно как для долговечности, так и для надежности, поскольку вы можете обнаруживать ошибки на ранних этапах, даже если современные браузеры их скрывают. И Jasmine, и Google Closure, основанные на JSUnit, хорошо подходят для тестирования.

Вы также захотите запустить полные функциональные тесты пользовательского интерфейса, в которых Selenium / WebDriver хороши. По сути, вы пишете программу, которая просматривает ваш пользовательский интерфейс и использует ее так, как если бы кто-то ее тестировал. Подключите их к сборочному боту.

Наконец, как уже упоминали другие, ваши данные - король. Продумайте модель хранения данных и убедитесь, что она рассчитана на длительное время. Убедитесь, что ваша схема данных надежна, и убедитесь, что она тщательно проверяется при каждом коммите. И убедитесь, что ваша серверная архитектура масштабируема. Это даже более важно, чем все, что вы делаете на переднем конце.

Ричард Коннамахер
источник
1
Хороший совет по «JS-фреймворкам» применим и к бэкэнд-фреймворкам. Посмотрите совет дяди Боба Мартина .
Брайан Лоу
Честно говоря, я буду осторожен с JS, учитывая контекст. Я могу представить, что HTML будет примерно через 40 лет; Я бы не стал полагаться на то, какой конвертер используется тогда, чтобы обязательно поддерживать JS так, как вы хотите (и учесть, что ваш JS, возможно, поступает неправильно, поскольку предпочтительное устройство вывода может быть невообразимо другим).
Имон Нербонн
10

Оставляя в стороне проблемы необоснованных ожиданий вашего клиента и сосредотачиваясь на вопросах дизайна, я бы не пошел так далеко, как 40 лет, но проблема, которую вы, похоже, испытываете, в отношении долгосрочной эволюционности, как раз и была создана для REST , Под этим я действительно подразумеваю REST как стиль архитектуры, а не разработку, основанную на модных словах, которая в наши дни так часто ассоциируется с термином.

В некоторой степени, люди неправильно понимают REST, потому что я не смог включить достаточно подробное описание дизайна медиа-типов в свою диссертацию. Это потому, что у меня не хватило времени, а не потому, что я думал, что это менее важно, чем другие аспекты REST. Кроме того, я подозреваю, что многие люди ошибаются, потому что они читают только статью Википедии на эту тему, которая не основана на авторитетных источниках.

Тем не менее, я думаю, что большинство людей просто делают ошибку, что должно быть просто проектировать простые вещи. На самом деле усилия, необходимые для разработки чего-либо, обратно пропорциональны простоте результата. Что касается архитектурных стилей, REST очень прост.

REST - это разработка программного обеспечения в масштабе десятилетий : каждая деталь предназначена для обеспечения долговечности программного обеспечения и его независимой эволюции.

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

Вы упомянули, что намереваетесь использовать интерфейс RESTful. Этот комментарий сам по себе предлагает вам провести серьезное исследование и попытаться понять, что же такое REST. Вы, вероятно, связываете это просто с отображением HTTP-методов в CRUD-операции, что большинство людей считают REST, но это не имеет к этому никакого отношения.

Думайте о REST как о формализации архитектуры самого Интернета. Так или иначе, есть много частей сети, написанных десять лет назад или более, которые все еще доступны и могут использоваться с клиентом, сделанным сегодня, поэтому мы кое-что правильно поняли в этом отделе. Это будет большая работа, я гарантирую вам, потому что правильно сделать REST сложно, но долгосрочные выгоды того стоят.

Педро Вернек
источник
Это очень полезно! Спасибо. Я провел еще несколько исследований в области REST, и я вижу, что это огромные преимущества и как его можно расширить за пределы методов HTTP. Это довольно мощный материал, и я очень рад работать с ним. Спасибо за ссылку! Я просто хотел бы иметь больше времени!
Пит
9

После того, как я прочитал вопрос и другие (очень хорошо продуманные) ответы, я подумал, что я тоже оставлю свои два цента. Примечание: мне не нужно поддерживать какое-либо действительно старое приложение / программное обеспечение. То, что я использую в качестве справочного материала, - это мое собственное веб-приложение для незавершенных работ, которое собирает некоторые открытые правительственные данные, анализирует и отображает их в различных форматах. Приложение началось как проект, в котором я не был одинок и где правительство только что объявило, что когда-нибудь предоставит эти данные. Таким образом, было ясно, что со временем многое изменится. И они сделали. Что я из этого узнал:

  • Разделите вещи в мини-приложениях. Каждый в полной мере способен выполнить свою задачу самостоятельно. Это делает переключение одной части очень быстрым, очень безопасным и очень простым. И когда вам нужно вернуться, нетрудно понять, почему что-то происходит и как вы это делаете. Если вам или кому-то еще придется что-то изменить позже, заменить одну деталь легче, чем целый набор вещей.
  • Получите постоянный промежуточный слой / слой, который используется для связи между различными частями. В этом случае я использовал JSON, но XML, ini или аналогичные стандарты тоже подойдут. Это легко повторить и может быть преобразовано почти во что угодно. Все это проверенные стандарты, которые выживут довольно долго. Даже если базовые данные и / или модель хранения будут изменены. Каждое из приложений может использовать свое собственное хранилище данных для своей конкретной задачи. Это делает объем отсканированных данных для задачи меньшим, что облегчает обработку и обслуживание и облегчает обмен.
  • Не беспокойтесь о решениях на языке программирования. Те будут меняться со временем. Просто убедитесь, что вы используете язык, который вам удобен или который лучше всего подходит для задачи.
  • Убедитесь, что ваше хранилище данных «масштабируемо по горизонтали» и что легко подключить дополнительные модули хранения.
  • Получить общую точку (в моем случае это URI), где мини-приложения называются и / или обмениваются данными.

Резюмируя: меня больше всего волнует разделение задач и возможность обмена частями, назначенными для задач. Вы просто знаете, что через 40 лет (даже через 5 или 10) аппаратное обеспечение, интерфейсы, хранилище и т. Д. Сильно изменятся. И позже разработчикам придется реагировать на эти изменения и обмениваться частями вашего приложения, будь то контейнер данных или части пользовательского интерфейса.

кайзер
источник
1
Очень хороший совет! Благодарю. Я определенно согласен с разделением задач и созданием мини-приложений. В текущей сборке все взаимосвязано, что затрудняет интеграцию новых функций и требований. Я надеюсь использовать интерфейс RESTful и использовать JSON. Не жаловаться, но когда я впервые присоединился, оффшорный архитектор не позволил мне использовать JSON. Поэтому я просто сказал ему, что передаю «строки», и пропустил ту часть, что эти строки были в формате JSON. :)
Пит
7

Чтобы сделать вещи как можно более перспективными, планируйте изменения. То есть изо всех сил старайтесь не оптимизировать что-либо, кроме способности легко меняться. Так что без нормализации, без строгой проверки и слабой связи в изобилии.

  • Используйте основные технологии с открытым исходным кодом. Для данных системы с закрытыми исходными кодами являются основным источником риска, так как нельзя планировать, какие компании пойдут или изменят стратегии, забирая с собой весь доступ к данным. Кроме того, незначительные проекты с открытым исходным кодом без активного сообщества также с большей вероятностью потеряют поддержку.

  • Используйте базу данных NoSQL без схемы. Разновидности неструктурированных данных, которые используются, почти прямо из учебника для хранилища документов, такого как MongoDB. Традиционные реляционные базы данных и их нормализация хороши, когда вы знаете, как будут структурированы ваши данные, но это действительно выдумка, особенно здесь. Затраты на изменение схемы в RDBS только увеличиваются и увеличиваются по мере расширения системы. Знайте, что любая структура, выбранная сейчас, в конечном итоге изменится.

  • Разъедините систему, используя широко принятые стандарты. Разбиение доступа к данным и их мутация в веб-сервисы - один шаг к этому. Объединение этого с очередями сообщений для отправки изменений и тому подобным поможет отдельным частям системы со временем менять языки или технологии.

phlogisticfugu
источник
К сожалению, использование базы данных без схемы не означает, что реструктуризация и реорганизация данных имеют нулевую стоимость.
Алекс Д
4

Хорошо, поэтому я собираюсь сказать кое-что здесь, которое, вероятно, будет довольно непопулярным, но придерживайтесь меня здесь.

Поскольку это ваш первый проект, в котором данные и / или приложение должны длиться более 20 лет, и вы являетесь руководителем проекта, вам необходимо сделать шаг назад и подумать о том, каковы шансы этого проекта на успех. , Потому что они в основном рядом с нулем.

Вам нужно потратить огромное количество времени на то, чтобы сосредоточиться на дизайне базы данных и сделать это правильно. Чтобы этот проект был успешным, вам нужно привлечь в проект архитектора данных, и скорее раньше, чем позже. Без кого-то, кто имеет опыт проектирования баз данных и кто хорошо знает, как рассчитывать на то, как эти данные могут быть использованы в будущем, шансы на то, что данные будут полезны через 5 лет, а тем более 40 лет, ничтожны.

Ожидается, что два человека (один из которых имеет звание младшего разработчика) построить что-то с нуля, что, как ожидается, продлится 40 лет, вряд ли удастся. Должна быть команда людей, многие из которых имеют опыт работы с такими крупными проектами, которые работают над дизайном данных, дизайном API и дизайном приложений. Как-то так, это не проект для двух человек.

Желание связать проект с чем-то вроде Drupal показывает, почему проекту нужны люди, которые привыкли работать над такого рода проектами. Вы не хотите привязывать приложение к чему-либо, что может выйти из моды всего через несколько лет. Если вы это сделаете, то найти кого-то, кто будет работать в системе через 5-10 лет, может очень быстро очень сложно.

Я бы отнес этот совет руководству и объяснил им, что вам нужно привлечь больше людей старшего уровня в проект. В противном случае проект обречен на провал, и вы, вероятно, в конечном итоге возьмете вину на себя.

mrdenny
источник
3

Приложение не должно выживать 40 лет без какой-либо эволюции. Но поскольку он будет или должен быть построен с нуля, он все еще может «функционировать».

Самое главное - это «архитектура данных», которая обеспечивает некоторую стабильность и управление, а также расширяемость.

Мы разработали архитектуру данных и таксономию, которые могли бы пережить конец человечества, но при этом быть расширяемыми. Вы должны найти истинного ТАКСОНОМИИ ДАННЫХ / АРХИТЕКТУРУ ДАННЫХ, чтобы сделать это для вас.

Алекс С
источник
Я думаю, что провал этого проекта с самого начала заключался в том, что он был запущен без должного архитектора данных. Это определенно очень здравый совет.
Пит
Время звонить и нанимать меня :) В некоторых компаниях мы делаем что-то для управления данными и таксономии :)
Alex S
3

Ключевым моментом здесь является сосредоточение на базе данных (как уже говорили несколько выше). Это должно быть последовательным и полностью описывать операцию. Это должно расти с операцией, поскольку это изменяется. Если это не легко изменить, то это устареет, и это поцелуй смерти. Остальное относительно менее важно.

Я не согласен с теми, кто выше, которые считают, что нормализация не важна, хотя всегда есть случаи, когда существующие системы не подходят для работы. В этих случаях денормализуйте, но убедитесь, что база данных обрабатывает дополнительные записи / изменения как часть атомарной транзакции. Таким образом, вы можете эффективно игнорировать проблему, пока не сможете ее исправить.

Компания, в которой я работал до выхода на пенсию, работает с системой, которая была написана с нуля и почти непрерывно росла в течение 25 лет и охватывает практически все аспекты деятельности среднего ритейлера. Аспекты этой системы, которые я считаю важными:

  • Интеграция жизненно важна.
  • База данных должна быть максимально точной и понятной как для ИТ-специалистов, так и для других сотрудников, поэтому требуется почти параноидальный акцент на именовании. У нас есть таблицы определенной мнемоники, которые затем объединяются, чтобы составить имена таблиц и полей, и все «коды» также были названы как константы и сохранены в структуре таблицы EAV.
  • Мы инкапсулировали бизнес-логику в триггеры базы данных. Сначала это болезненно и требует дополнительной работы для передачи сообщений об ошибках клиентам и обеспечения возможности гибкого изменения триггеров без блокировки всей таблицы в некоторых системах, но это быстро экономит время и заставляет базу данных быть намного более корректной чем иначе.
  • Предположим, что вы сохраните хотя бы справочные таблицы (в идеале все, кроме самых быстрых и наименее важных транзакций) в течение всей жизни системы, даже если они «удалены», поэтому ваши ссылки верны.
  • Из-за вышеизложенного убедитесь, что любые уникальные идентификаторы и номера транзакций рассчитаны на длительный срок. (Первоначально я в шутку предположил, что они должны продлиться до моей отставки).
Буш Ал
источник
2

Я бы предложил использовать распределение событий и разделение ответственности по командам и запросам . Это главным образом потому, что единственное, в чем вы можете быть уверены, это события, которые уже появились. Новые типы событий могут прийти. Таким образом, даже если вы будете задумываться о модели, она наверняка устареет. Перенос всех данных с каждым выпуском может оказаться невозможным. Поэтому лучше всего иметь модель, которая соответствует вашим текущим потребностям и рассчитывается на основе уже записанных событий каждый раз, когда вам это нужно, а затем выдавать события, которые рассчитываются на основе текущего состояния этой модели.

Также имейте в виду тестирование. Если приложение будет использоваться через десять лет, тестеры должны убедиться, что оно все еще делает то, что должно делать. Поэтому сделайте интеграционное тестирование своего приложения максимально простым.

SpaceTrucker
источник