Причины различий SQL
Я не могу найти чистое решение CSS. Вот решение, использующее JavaScript-библиотеку CSS Element Queries .
var aspectRatio = 16/9;
var element = document.querySelector('.center');
function update() {
element.style.width = (element.clientHeight * aspectRatio) + 'px';
}
new ResizeSensor(element, update);
update();
5 ответов
Это - форма "Скрытой привязки". Joel вдается в большие подробности здесь:
- http://www.joelonsoftware.com/articles/fog0000000056.html
- http://www.joelonsoftware.com/articles/fog0000000052.html
Компании заканчивают тем, что связали свою бизнес-функциональность с нестандартной или странной неподдерживаемой функциональностью в их реализации, это ограничивает их способность переехать от их поставщика конкуренту.
С другой стороны, это довольно близоруко, потому что любой с половиной мозга будет склонен абстрагировать далеко собственные части или избежит привязки в целом, если это станет слишком вопиющим.
Стандарт ANSI указывает только ограниченный набор команд и типов данных. После того как Вы идете вне тех, конструкторы самостоятельно. И некоторые очень важные понятия не указаны вообще, такие как автопостепенное увеличение столбцов. SQLite просто выбирает первое непустое целое число, MySQL требует AUTO INCREMENT, PostgreSQL использует последовательности и т.д. Это - путаница, и это только среди баз данных OSS! Попытайтесь заставить Oracle, Microsoft и IBM коллективно выбирать хитрый бит функциональности.
Во-первых, я не нахожу, что базы данных как, скажем, браузеры или операционные системы с точки зрения несовместимости. Любой с несколькими часами обучения может начать делать, выбирает, вставляет, удаляет и обновляет на любой базе данных SQL. Между тем трудно записать HTML, который представляет тождественно на каждом браузере или системном коде записи больше чем для одной ОС. Обычно различия в SQL связаны с производительностью или довольно тайными функциями. Основное исключение, кажется, форматы даты и функции.
Во-вторых, разработчики базы данных обычно мотивируются для добавления опций, которые дифференцируют их продукт от всех остальных. Продуктами как Oracle, SQL Server MS и MySQL являются обширные экосистемы, которые редко перекрестный опыляют на практике. На моем рабочем месте мы используем Oracle и MySQL, но мы могли, вероятно, переключиться на 100% Oracle приблизительно через день в случае необходимости или желаемый. Таким образом, я забочусь много о солнечных игрушках, которые Oracle дает нам с каждым выпуском, но я даже не знаю, какую версию MySQL мы используем. IBM, Microsoft, PostgreSQL и остальные не могли бы также существовать, что касается нас. Наличие функций, чтобы добраться и сохранить клиентов и пользователей намного более важно, чем совместимость в мире базы данных. (Это - положительное вращение на ответе "привязки", я предполагаю.)
В-третьих, существуют законные причины для различных компаний для реализации SQL по-другому. Например, Oracle имеет мультисистему управления версиями, которая позволяет очень быстрые и масштабируемые последовательные чтения. Другое отсутствие баз данных, что функция, но обычно быстрее вставляют строки и откатывают транзакции. Это - принципиальное различие в этих системах. Это не делает один лучше, чем другой (по крайней мере, в общем случае), просто отличающийся. Не нужно удивляться, использует ли SQL ontop механизма базы данных в своих интересах свои преимущества и пытается минимизировать свои слабые места. На самом деле было бы безответственно из разработчиков не сделать это.
John: стандарт на самом деле касается большого количества предметов, включая столбцы идентификационных данных, последовательности, триггеры, стандартные программы, upsert, и т.д. Но конечно, многие из этих компонентов стандартов, возможно, были принесены на месте позже, чем первые реализации; и это могло быть причиной, почему соответствие стандартов SQL является несколько низким, обычно.
Neall: существуют на самом деле области, где стандарт SQL перед реализациями. Например, было бы хорошо иметь, СОЗДАЮТ УТВЕРЖДЕНИЕ, но насколько я знаю, никакой DBMS еще не реализует утверждения.
Лично, я полагаю, что закрытая природа некоторых стандартов ISO (как стандарт SQL) является частью проблемы: Когда стандарт не будет легко доступен онлайн, он, менее вероятно, будет известен конструкторам/планировщикам, и слишком мало клиентов просит соответствие, потому что они не знают, что попросить.
Это - конечно, эффективная привязка, как говорит 1800. Но объективности ради по отношению к поставщикам базы данных, стандарт SQL всегда играет в догонялки к наборам функций текущих баз данных. Большинство баз данных, которые мы имеем сегодня, имеет довольно древние происхождения. Если Вы прослеживаете Microsoft SQL Server до его корней, я думаю, что Вы найдете Ingres - одна из самых первых реляционных баз данных записанный в 70-х. И Пост-ГРЭС была первоначально записана некоторыми из тех же людей в 80-х как преемник Ingres. Oracle идет путем назад, и я не уверен, где MySQL вошел.
Немобильность базы данных действительно сосет, но это могло быть намного хуже.