Какие аргументы использовать для объяснения, почему SQL Server намного лучше, чем плоский файл

• Сколько времени нужно на такое масштабное перезапись / переключение и огромные затраты

Это не просто количество времени, это введение новых ошибок. Переписывание этих пропорций приведет к поломке того, что сейчас работает.

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

Менеджеры любят числа, поэтому проводите формальный письменный анализ решений. Сравните два предложения по преимуществам и рискам, а также числовым значениям. Когда у вас будет 0 затрат на обслуживание и 100000000 на преобразование, они получат балл.

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

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

Итак, вместо того чтобы обосновывать, почему SQL лучше плоских файлов, я бы перевернул проблему и спросил, какие проблемы призваны решить плоские файлы. Я бы поставил на то, что это проблема коммуникации.

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

Самый простой способ опровергнуть этот аргумент - назвать компанию из списка Fortune 500, которая обрабатывает данные в этом масштабе с помощью плоских файлов?

Теперь назовите состояние. 500 компаний, не использующих реляционную базу данных ...

Дело закрыто.

Я предлагаю вам сначала получить свою отповедь, опубликуйте ее на Daily WTF.

Что касается вашего вопроса: деловой причиной было бы то, почему ваш босс хочет переписать все ваши системы. С нуля, поскольку вам, по сути, придется писать собственную систему баз данных.

С точки зрения разработки, вы потеряете доступ к экосистеме SQL-сервера, всем библиотекам, инструментам, утилитам.

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

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

Фрагментация становится проблемой, и вы теряете кое-где текстовый файл, что приводит к потере небольших объемов данных. При проектировании базы данных работоспособность жесткого диска не должна быть проблемой.

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

Однако я бы рекомендовал, если вы говорите с техническим специалистом, избегать технических причин в рекомендациях, потому что они могут показаться предвзятыми.

Вот два моих аргумента против хранения данных в плоских файлах:

1) Безопасность - аудиты HIPPA требуют, чтобы данные пациента хранились в безопасной среде. Распространенные системы баз данных (Oracle, Microsoft SQL, MySQL) имеют методы для реализации доступа к безопасности в соответствии с HIPPA. Сделать это на плоском файле будет в лучшем случае сложно.

Примечание: я также видел медицинские практики, которые шифруют имя пациента в базе данных, чтобы добавить дополнительные уровни защиты и соответствия, чтобы гарантировать, что даже если их БД будет взломана, записи пациентов не подвергнутся риску.

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

Надеюсь, это поможет.

Если вы публичная компания, акционерам будет полезно знать, что это серьезно рассматривается. «Мы» все знаем, что это нелепое предложение, учитывая размер и масштаб вашей операции. Записи пациентов должны быть защищены не только от нарушений безопасности, но и от безответственного ущерба - жизни могут зависеть от данных . Если руководители вообще заботятся о пациентах, ЭТО должно быть их самой большой заботой.

Я работал с мэйнфреймами IBM 370 начиная с 1974 г., и день, когда DB2 заменил простые старые плоские файлы, VSAM и ISAM, стал важной вехой. За 25 лет работы с РСУБД 4-х видов я ни разу не оглядывался на хранилище плоских файлов, за исключением потоковой передачи данных.

Если бы я владел акциями «вас», то поспешно выбросить их в тот момент, когда проект взлетел, казалось бы уместным ...

Я не думаю, что смогу даже начать перечислять причины. Думаю, моя голова вот-вот взорвется. Я рискну и попытаюсь помочь вам ...

• Смоделируйте сбой в сети и покажите, что происходит с одним из файлов в этот момент.
• Демонстрируйте ужасы полузавершенной транзакции, потому что текстовые файлы не не прошли тест ACID
• Если это многопользовательское приложение, покажите, сколько времени клиенту придется ждать, когда все 500 подключений пытаются обновить один и тот же текстовый файл
• Попытайтесь вежливо объяснить, почему лучший подход к созданию бизнес-решения - это прислушиваться к профессионалам, которым вы платите деньги и которые знают домен (в данном случае, ИТ), а не к вашему приятелю, который не имеет ни малейшего понятия (возможно, оставьте последний бит).
• Упомяните факт что 99% (составляющее число) в деловом мире используют реляционные базы данных для своих важных данных, а не текстовые файлы, и, вероятно, для этого есть причина
• Покажите, что происходит с вашим приложением, когда кто-то входит в текстовый файл и вводит " ха-ха! " для столбца, который должен быть целым числом

У вас хорошее начало списка. Я бы добавил следующие пункты:

1. Целостность данных - SQL-движки предоставляют встроенные механизмы (отношения, ограничения, триггеры и т.д.), которые позволяют очень просто уменьшить количество "плохих" данных в вашей системе. При использовании плоских файлов вам придется вручную разрабатывать все ограничения данных.
2. Дополнительный поиск данных - SQL-движки, благодаря использованию операторов SELECT, предоставляют средства фильтрации и обобщения данных с очень небольшим количеством кода. Если вы используете плоские файлы, то для получения тех же результатов требуется значительно больше кода.

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

Я бы также упомянул о повреждении данных. В большинстве современных баз данных SQL можно отключить питание на сервере, или серверный экземпляр может упасть, и вы не потеряете (не должны) данные. С плоскими файлами дело обстоит иначе.

Также я бы упомянул время поиска. Возможно, даже напишите простую базу данных плоских файлов с 1 млн. записей и покажите время поиска по сравнению с MS SQL. С индексами вы сможете искать в базе данных SQL в тысячи раз быстрее.

Я бы также был осторожен с тем, как быстро вы списываете плоские файлы со счетов. Я бы сказал: "Это хорошая идея для многих случаев, но в нашем случае....". Так вы не будете выглядеть так, будто не прислушиваетесь к другим мнениям. Такт в подобных ситуациях - это главное, что нужно учитывать. Они могут быть ужасно неправы, но вы должны убедить в этом своего начальника.

Если вы используете «текстовые файлы», вам нужно будет построить поверх него интерфейс, который Microsoft уже сделала для вас и назвала его SQL Server.

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

• Производительность: SQL Server создан для хранения удобных для поиска данных. Он оптимизировал структуры данных в памяти, построенной с учетом поиска / вставки / удаления. Использование диска снижается, поскольку регулярно запрашиваемые данные хранятся в памяти.

• Деловые партнеры: если вы когда-нибудь планируете вести B2B-бизнес со сторонними компаниями, SQL Server имеет для этого встроенную функцию, называемую «Связанные серверы». Если у вас всего несколько файлов, ваш деловой партнер откажется от вас, поскольку обмен данными невозможен. Если только вы не хотите снова изобретать колесо и создавать интерфейс для каждого вашего делового партнера.

• Кластеризация: вы можете легко кластеризовать серверы в SQL Server для обеспечения высокой доступности и скорости, намного больше, чем это возможно с помощью текстового решения.

Что они получают от использования плоских файлов? Процесс конвертации займет сотни часов - часы, за которые они платят. Как быстро плоские файлы могут принести положительную отдачу от вложенных средств? Предоставьте приблизительную смету. Переведите технические соображения в деньги (затраты), и вы увидите проблему с их точки зрения.

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

• Индексирование
• Обработка транзакций
• Ведение журнала
• Контроль доступа
• Производительность
• Безопасность

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

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

Как создать реляционную модель с простыми текстовыми файлами?

Или вы планируете использовать разные файлы для каждой сущности?

Файловая система Pro:

1. Стабильная (меньше строк кода = меньше ошибок, проще для понимания, более надежно)
2. Быстрее с огромными большими двоичными данными
3. Поиск / сортировка в некоторой степени медленно (но sort может быть быстрее, чем порядок в SQL на )

Итак, вы, например, выбрали бы файловую систему для создания файлов журнала. Вход в БД бесполезен, если вам не нужно проводить сложный анализ данных.

Pro DB:

2. Транзакции (включая одновременный доступ)
3. Он может выполнять поиск в огромных количествах записей (но не в огромных блоках данных)
4. Обрезка данных во всех способы с запросами просты (ну, если вы знаете свой SQL и особые "странности" вашей БД)

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

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

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

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

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

Люди, которые не делают различий между плоскими файлами и sql, не понимают всех аргументов, которые вы говорите до этого.

Объяснение должно быть как можно более простым, что-то вроде этого:
SQL - это своего рода поисковая/валютная обертка вокруг плоских файлов.
Все проблемы, которые существуют сейчас, останутся, даже если компания напишет обертку с нуля.

Также вы должны дать какой-то другой способ решения текущих проблем, используйте умные слова вроде advanced BLL или install/uninstall scripting environment. :)

Это действительно, со стороны вашего работодателя, MAJOR WTF, если он серьезно предлагает плоские файлы для всего...

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

Прежде всего, я бы написал сценарий в том инструменте, который вы сейчас используете, для выполнения базовой операции с помощью SQL, и запустил бы его по времени. Затем я бы написал другой сценарий, в котором вы искренне попытаетесь заставить работать решение на основе плоского текста, а затем выделил бы разницу в производительности. Дайте ему оба набора кода, чтобы он знал, что вы не обманываете".

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

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

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

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

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

Удачи вам в этом - я чувствую вашу боль...

Мартин