Зачем использовать базу данных SQL?

Ответ 1

Если все, что вам нужно сделать, - это где-то хранить некоторые данные приложения, то RDBMS общего назначения или даже SQLite может быть переполнена. Сериализация ваших объектов и запись их в файл может быть проще в некоторых случаях. Преимущество SQLite заключается в том, что если у вас много такого рода информации, все они содержатся в одном файле. Недостатком является то, что читать его сложнее. Например, если вы упорядочиваете данные в YAML, вы можете прочитать файл с помощью любого текстового редактора или оболочки.

Лично я бы использовал некоторые 'compiled db query' байт-код, что будут собраны один раз внутри клиентского приложения и базы данных.

Вот как работают некоторые API баз данных. Проверьте статические SQL и подготовленные операторы.

Есть ли какая-то причина для меня не написать его сам и использовать SQL вместо базы данных?

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

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

UPDATE:

Но зачем использовать язык SQL для взаимодействие с такой базой данных?

Хороший вопрос.

Ответ на это можно найти в оригинальной статье, описывающей реляционную модель Реляционная модель данных для крупных общих банков данных, EF Codd, опубликованный IBM в 1970 году. В этом документе описываются проблемы с существующими технологиями баз данных того времени и объясняется, почему реляционная модель превосходит.

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

Независимость данных определяется в документе как:

"... независимость прикладных программ и терминальных действий от роста типов данных и изменений в представлениях данных."

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

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

Таким образом, мы используем SQL, потому что мы используем реляционную модель для наших баз данных.

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

ОБНОВЛЕНИЕ 2:

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

Поскольку база данных является реляционной базой данных, она понимает только языки реляционных запросов. Внутри он использует реляционную алгебру, такую ​​как язык, для указания запросов, которые затем превращаются в план запросов. Таким образом, мы пишем наш запрос в форме, которую мы можем понять (SQL), DB берет наш SQL-запрос и превращает его в свой внутренний язык запросов. Затем он берет запрос и пытается найти "план запроса" для выполнения запроса. Затем он выполняет план запроса и возвращает результат.

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

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

Ответ 2

Каждый, кого я знаю, включая меня, использует ORM

Странно. Все, кого я знаю, включая меня, все еще записывают большую часть SQL вручную. Как правило, вы получаете более строгие запросы с более высокой производительностью, чем с созданным решением. И, в зависимости от вашей отрасли и приложения, эта скорость имеет значение. Иногда много. да, я иногда использую LINQ для быстрого n-грязного, где мне все равно, как выглядит итоговый SQL, но до сих пор ничто не автоматизировало, если бы он настраивал SQL вручную, когда производительность по сравнению с большой базой данных в высокопроизводительной базе данных, нагрузка действительно важна.

Ответ 3

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

• Индексы - вы можете хранить большие объемы данных и по-прежнему иметь возможность фильтровать и искать очень быстро из-за индексов. Конечно, вы можете реализовать свою индексацию, но зачем изобретать колесо

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

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

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

Ответ 4

Здесь есть хорошие ответы. Я попытаюсь добавить свои два цента.

Мне нравится SQL, я могу думать в нем довольно легко. Запросы, создаваемые слоями поверх БД (например, рамки ORM), обычно отвратительны. Они будут выбирать тонны дополнительных вещей, присоединяться к вещам, которые вам не нужны, и т.д.; все потому, что они не знают, что вы хотите получить небольшую часть объекта в этом коде. Когда вам нужна высокая производительность, вы часто входите и используете по крайней мере некоторые пользовательские SQL-запросы в системе ORM, чтобы ускорить несколько узких мест.

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

Разбирает SQL неэффективно? В некотором роде. Грамматика довольно структурирована, поэтому нет тонны двусмысленностей, которые сильно затрудняли бы работу с парсером. Реально, что накладные расходы на разбор SQL в основном ничего.

Скажем, вы запускаете запрос типа "SELECT x FROM table WHERE id = 3", а затем делаете это снова с 4, затем 5, снова и снова. В этом случае могут существовать служебные данные синтаксического анализа. Вот почему вы подготовили заявления (как указывали другие). Сервер анализирует запрос один раз и может поменять местами 3 и 4 и 5, не переписывая все.

Но это тривиальный случай. В реальной жизни ваша система может присоединиться к 6 таблицам и вынуждена вытягивать сотни тысяч записей (если не больше). Это может быть запрос, который вы можете запускать в кластере базы данных в течение нескольких часов, потому что это лучший способ сделать что-то в вашем случае. Даже при выполнении запроса, выполняющего только минуту или две, время для разбора запроса по существу бесплатное по сравнению с извлечением записей с диска и выполнением сортировки/агрегации/и т.д. Накладные расходы на отправку ext "LEFT OUTER JOIN ON" составляют всего несколько байтов по сравнению с отправкой специального закодированного байта 0x3F. Но когда ваш результирующий набор равен 30 МБ (не говоря уже о концертах +), эти несколько лишних байтов бесполезны по сравнению с тем, что им не нужно связываться с каким-то специальным объектом компилятора запроса.

Многие люди используют SQL для небольших баз данных. Самый большой, с которым я общаюсь, - всего несколько десятков концертов. SQL используется для всего, от крошечных файлов (например, небольших SQLite DB) до кластеров Oracle размером до терабайта. Учитывая его силу, это на самом деле удивительно простой и небольшой набор команд.

Ответ 5

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

Ответ 6

Но зачем использовать язык SQL для взаимодействия с такой базой данных?

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

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

Это существующая (необязательная) функция баз данных, называемая "хранимые процедуры".

Edit:

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

Когда я реализовал свой собственный ORM, я реализовал структуру ORM с помощью ADO.NET: и использование ADO.NET включает использование SQL-инструкций в его реализации.

Ответ 7

Да, раздражает необходимость писать инструкции SQL для хранения и извлечения объектов.

Вот почему Microsoft добавила такие вещи, как LINQ (интегрированный язык) в С# и VB.NET, чтобы можно было запрашивать базы данных с использованием объектов и методов вместо строк.

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

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

Ответ 8

После всех изменений и комментариев основной вопрос вашего вопроса выглядит следующим образом: почему природа SQL ближе к интерфейсу человека/базы данных, чем к интерфейсу приложения/базы данных?

И очень простой ответ на этот вопрос: потому что это именно то, что изначально предназначалось для него.

Предшественники SQL (QUEL, предположительно, самый важный) были предназначены именно так: язык QUERY, то есть тот, у которого не было никаких INSERT, UPDATE, DELETE.

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

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

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

Ответ 9

Моя самая большая причина для SQL - это отчетность Ad-hoc. Этот отчет хочет, чтобы ваши бизнес-пользователи захотели, но не знают, что им это нужно.

Ответ 10

SQL - это общий интерфейс, используемый платформой СУБД - вся точка интерфейса заключается в том, что все операции с базой данных могут быть указаны в SQL без необходимости дополнительных вызовов API. Это означает, что существует общий интерфейс для всех клиентов системы - прикладное программное обеспечение, отчеты и специальные инструменты запросов.

Во-вторых, SQL становится все более полезным, поскольку запросы становятся более сложными. Попробуйте использовать LINQ, чтобы указать 12-way join a с тремя условиями на основе экзистенциальных предикатов и условием, основанным на агрегате, вычисленном в подзапросе. Подобная вещь достаточно понятна в SQL, но вряд ли возможна в ORM.

Во многих случаях ORM будет делать 95% того, что вы хотите - большинство запросов, выданных приложениями, - это простые операции CRUD, которые могут легко обрабатывать ORM или другой общий механизм интерфейса базы данных. Некоторые операции лучше всего выполнять с использованием пользовательского кода SQL.

Однако ORM - это не все и все интерфейсы базы данных. Шаблоны Fowler архитектуры корпоративных приложений имеют довольно хороший раздел по другим типам стратегии доступа к базам данных с некоторым обсуждением достоинств каждого из них.

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

Однако конечная причина, по которой вы не можете игнорировать SQL, заключается в том, что вы в конечном итоге работаете с базой данных, если вы делаете приложение базы данных. Существует много, много историй WTF об ошибках в коммерческом коде приложения, сделанных людьми, которые не понимают базы данных должным образом. Плохо продуманный код базы данных может вызвать проблемы по-разному, и беспечно думает, что вам не нужно понимать, как работает СУБД, - это поступок Hubris, который обязательно придет и укусит вас когда-нибудь. Хуже того, он придет и укусит другого бедного schmoe, который наследует ваш код.

Ответ 11

Пока я вижу вашу точку зрения, язык запросов SQL имеет место, особенно в больших приложениях с большим количеством данных. И указать на очевидное, если языка там не было, вы не могли бы назвать его SQL (Structured Query Language). Преимущество использования SQL над описанным вами методом является, как правило, очень читаемым, хотя некоторые действительно ограничивают их запросы.

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

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

Ответ 12

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

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

Ответ 13

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

Я использую sqlite намного правее от самых простых задач (например, ведение журналов брандмауэра непосредственно в базе данных sqlite) до более сложных аналитических и отладочных задач в своих ежедневных исследованиях. Упорядочение моих данных в таблицах и запись SQL-запросов для их извлечения интересными способами кажутся наиболее естественными для меня в этих ситуациях.

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

• Существует около 3-4 лет серьезные исследования в этой области начиная с 1970 года с оригинальной Codd paper О реляционной алгебре. Реляционная алгебра формирует математическая основа SQL (и другие QL), хотя SQL не полностью следовать реляционным модель.

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

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

Вопрос, который затем становится интересным, спрашивает: "Каковы реальные преимущества выполнения SQL в любом другом" нетекстовом "способе?" Будет ли Google для этого сейчас:)

Ответ 14

SQL был создан для обеспечения интерфейса для создания специальных запросов к реляционной базе данных.

Как правило, большинство реляционных баз данных понимают ту или иную форму SQL.

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

Реляционные базы данных также позволяют работать в "отключенном" состоянии. После того, как у вас есть запрошенная информация, вы можете закрыть соединение с базой данных. С базой данных OO вам нужно либо вернуть все объекты, связанные с текущим (и те, с которыми они связаны... и... и т.д.), Либо повторно открыть соединение для извлечения новых объектов, поскольку они доступ.

В дополнение к SQL у вас также есть ORM (объектно-реляционные сопоставления), которые сопоставляют объекты с SQL и обратно. Их довольно много, включая LINQ (.NET), MS Entity Framework (.NET), Hibernate (Java), SQLAlchemy (Python), ActiveRecord (Ruby), Class:: DBI (Perl) и т.д..

Ответ 15

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

Во второй части вы, кажется, жалуетесь на то, что SQL является текстовым (он использует строки вместо ids и т.д.)... SQL - это язык запросов. Любой язык (компьютер или другой), предназначенный для чтения или написания человеком, является текстовым, ориентированным на это. Assembly, C, PHP, вы называете это. Зачем? Потому что, ну... это имеет смысл, не так ли?

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

Ответ 16

да, текст немного неэффективен. Но на самом деле получение данных намного дороже, поэтому текст на основе sql является существенно незначительным.

Ответ 17

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

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

Ответ 18

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

• Полу-произвольные решения, когда они были разработаны, такие как простота использования, не нуждающиеся в компиляторе SQL (или IDE), переносимости и т.д.
• Случилось хорошо поймать (возможно, по сходным причинам)
• И теперь по историческим причинам (совместимость, хорошо известная, проверенная и т.д.) по-прежнему используется.
• Я не думаю, что большинство компаний беспокоило другое решение, потому что оно работает хорошо, это не слишком узкое место, это стандарт, бла, бла..

Ответ 19

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

И я полагаю, именно поэтому мы обычно используем SQL вместо некоторого "байтового-SQL", который имеет только интерфейс компиляции. Даже если бы у нас был байтовый SQL, кто-то написал "Text SQL", и цикл был бы полным.

Кроме того, MySQL и SQLite менее полнофункциональны, чем, скажем, MSSQL и Oracle SQL. Таким образом, вы все еще находились в нижней части пула SQL.

Ответ 20

На самом деле есть несколько не-SQL-данных (например, Objectivity, Oracle Berkeley DB и т.д.), но не их удалось. В будущем, если кто-то найдет интуитивную альтернативу для SQL, это ответит на ваш вопрос.

Ответ 21

Существует множество нереляционных систем баз данных. Здесь только несколько: Memcached Токийский кабинет

Ответ 22

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

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

Ответ 23

Потому что часто вы не можете быть уверены, что (цитируя вас) "никто не видел после развертывания". Знание того, что есть простой интерфейс для отчетности, а для запросов уровня данных - хороший путь для эволюции вашего приложения.
Вы правы, что есть другие решения, которые могут быть действительными в некоторых ситуациях: XML, текстовые файлы, OODB...
Но наличие набора общих интерфейсов (например, ODBC) является огромным плюсом для жизни данных.

Ответ 24

Я думаю, что причиной могут быть алгоритмы поиска/поиска/захвата, с которыми связан sql laungage. Помните, что sql был разработан в течение 40 лет - и цель была как предварительной, так и пользовательской, дружелюбной.

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

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

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

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

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

Ответ 25

Я думаю, вы можете использовать ORM

тогда и только тогда, когда вы знаете базовое значение sql.

иначе результат не лучший