Как Вы пишете свои приложения, чтобы быть независимой базой данных?
Думаю, это то, что вы хотите:
>>> s = '(some, word), (someword), (some other, word)'
>>> re.findall('\(.*?\)', s)
['(some, word)', '(someword)', '(some other, word)']
Я думаю, что вы поняли, потому что кто-то думает, что вы не приложили усилия к вашей проблеме / к регулярному выражению.
5 ответов
Для отделения механизма базы данных из приложения используйте уровень абстракции базы данных (также уровень доступа к данным или DAL). Вы не упоминали, какой язык Вы используете, но существуют хорошие библиотеки абстракции базы данных для всех главных языков.
Однако путем предотвращения определенной для базы данных оптимизации Вы будете пропускать преимущества своего конкретного бренда. Я обычно краткий обзор, что возможно и использует то, что доступно. Изменение механизмов базы данных является важным решением и часто не происходит и лучше использовать инструменты, которые Вы имеете в наличии для максимум.
Скажите Вашему боссу заниматься своим делом. Нет, конечно, нельзя сказать такие вещи боссу, но остаться настроенным.
То, что интересно, - то, какая бизнес-возможность, как предполагается, поддерживается этим требованием. Один очевидный кандидат, кажется, что код базы данных должен быть готов к работе над другими механизмами базы данных, чем ток. Если это так, затем это - то, что должно быть указано в требовании.
Оттуда Вам решать как инженер для выяснения различных способов достигнуть этого. Можно было бы писать ANSI SQL. Можно было бы использовать уровень абстракции базы данных.
Далее это - Ваша обязанность сообщить Вашему боссу, что затраты на различные альтернативы (с точки зрения производительности, скорости разработки, и так далее).
"Запишите ANSI SQL"... gah!
Вы могли использовать один из многих инструментов Object/Relational Mapper, как Hibernate/NHibernate, LLBLGen, и т.д. Это может получить Вас длинный путь к мобильности базы данных. Независимо от того, что Вы делаете, у Вас должен быть некоторый уровень абстракции между Вашей моделью и остальной частью Вашего кода. Это не означает необходимость в своего рода инфраструктуре внедрения зависимости но хороший дизайн OO может получить Вас довольно далеко. Кроме того, продолжая работать с плоскостью SQL и думая это получит Вас, мобильность довольно наивна. Это было бы верно, если бы Ваше приложение было тривиально и только использовало очень тривиальные запросы.
Что касается всегда записи приложения, чтобы быть "любой готовой базой данных", я обычно использую своего рода уровень абстракции, таким образом, не трудно переместиться от одной системы баз данных до другого. Однако при многих обстоятельствах, это не требуется, Вы разрабатываете для платформы Oracle или SQL Server или MySQL вообще, таким образом, Вы не должны жертвовать преимуществами своего выбранного RDBMS только для возможности совершенно бесшовного перехода. Тем не менее, при создании хорошего уровня абстракции даже предназначаться для определенного RDBMS не обязательно будет слишком трудным для миграции на другой RDBMS.
Только для справки. Существует подобный вопрос здесь на Stackoverflow:
Проектирование баз данных для агностических базой данных приложений
Быть 100%, совместимыми к ANSI SQL, является трудной целью встретиться, и все же это не гарантирует мобильности так или иначе. Таким образом, это - искусственная цель.
По-видимому, Ваш босс просит это для упрощения и быстрый для переключения брендов базы данных для некоторой гипотетической цели в будущем (который на самом деле никогда не может прибывать). Но он обменивает ту будущую эффективность на больший объем работы теперь, так как более трудно сделать код нейтральным в отношении базы данных.*
Таким образом, если можно формулировать проблему с точки зрения целей менеджер должен фокусироваться на, как окончание текущего этапа проекта вовремя и на бюджете, это может быть более эффективно, чем просто сообщение ему, слишком трудно сделать код нейтральным в отношении базы данных.
Существует сценарий, когда необходимо сделать действительно нейтральный в отношении базы данных код, это - при разработке приложения термоусадочной пленки, которое требуется, чтобы поддерживать несколько брендов базы данных.
Так или иначе даже при текущей поддержке только одного бренда существуют, конечно, случаи, где у Вас есть выбор кодировать некоторый SQL, использующий собственные функции, но там также существует более портативный способ достигнуть того же результата. Можно рассматривать их как случаи "низко висящего плода", и можно помочь портировать код в будущем, если потребность возникает. Но не ограничивайте себя также, используйте собственные решения, если они дают хорошее значение. Возможно, добавьте примечание в комментариях, что это заслуживает обзора, если/когда необходимо сделать порт.
* я предпочитаю слово, "нейтральное" вместо "агностика" при разговоре о независимости от платформы. Это избегает религиозного обертона. :-)