При этом я не соглашусь что SQL субд работают медленно.
Этого я и не утверждал, в общем-то.
Более того зачастую то что в таких базах идет из коробки, большинство программистов не сможет написать оптимальнее, без багов и за разумное время.
Дело не в том, может кто-то конкретный написать лучше или не может.
Руляционная СУБД — это некоторым образом вещь в себе. Она доступна нам в виде интерфейса высокого уровня, плюс несколько ручек, которые можно крутить — всякие размеры кеша и подобное. У такого подхода есть некоторые ограничения. Например, иногда программист может составить лучший план для какого-то конкретного запроса, чем это делает сама субд. Он может косвенно влиять на выбор плана — например, через создание/удаление индекса, но это именно что косвенное влияние. Соответственно, крутые спецы по базам данных из-за этого в некотором роде похожи на шаманов — если тут ударить в бубен и там станцевать, то может пойти дождь, но это не точно.
Под database first подходе подразумевается вся бизнес-логика в виде хранимых процедур? Ну, это тоже антипаттерн.
Если нет, и вы имеете в виду куски чистого sql вперемешку с обычным кодом, то представьте следующее. Вам нужно отдать список чего-то по запросу, и в этом запросе может быть десяток различных параметров фильтрации. Представляете, насколько криво и нечитаемо будет смотреться конкатенация строк чистого sql запроса в таком контроллере?
Чтобы не спорить из-за терминов, давайте представим, что вместо ORM я привел в пример query builder. Суть моего сообщения от этого не изменится — писать в проекте на чистом sql обычно считается плохим тоном.
а почему вы так считаете? Просто от того, что ему чуть менее 50 лет? Не стильно-модно-молодежно?
Просто от того, что SQL создавался не как язык для программистов, а как язык для менеджеров. Мол, обычный человек сможет извлекать нужные ему данные по нужным критериям, без участия программистов. В итоге получился язык, сильно похожий на естественный. Манипулировать им — довольно сложно. Для машин нужен нормальный машинный или полу-машинный формат, типа json или что-то подобное.
Представьте, если бы по http-апи приходили параметры запроса не в таком виде: {id: 1, name: «Joe», ...}, а в виде обычного текста «user with id 12, name Joe, ...» и вам надо было сначала его парсить, потом что-то с ним делать, потом обратно превращать в обычный текст и отдавать обратно. Да вы бы первый сказали «вы тут что, больные все собрались?» и уволились бы оттуда.
Или разметка сайта не тегами "\<html\>...\<body\>....\</body\>\<html\>" бы делалась, а текстом типа: «Документ с заголовком: название заголовка. Содержимое документа: блок такой-то с содержимым таким-то».
Но базы данных — это сложная тема, тут не любят изменений, а на первое место выходит надежность. Плюс уже полвека так работает, все привыкли. Но это не значит, что не существует лучшего пути. В конечном счете, сами базы данных не с текстом ведь работают, они у себя внутри парсят запросы на синтаксические деревья в пригодном для машинной обработки виде.
Огромное количество ОРМ придумано потому, что люди не хотят напрямую работать с чистым sql. Но эта практика изначально порочна, потому что в конечном счете надо трансформировать запрос обратно в «человеческий» язык, перед отправкой в базу данных, со всеми его ограничениями.
С вами там все в порядке? Может температуру померить? Я тоже, естественно не считаю.
Это вы начали говорить о том, что мак появился из ничего, без исходников. Не уверен, что именно мне тут надо мерить температуру :)
Тут речь об аналогичности задачи без знаний о требованиях при пересадке/линковки. Пересадка почки раньше была невозможна без знаний и технологий как и искусственный интеллект, а человек остается просто человеком.
Аналогичности тут нет никакой. Пересадка головы — это замена устройства на аналогичное с тем же интерфейсом. То, о чем говорите вы — это как смешать днк человека и черепахи так, чтобы создать новый вид — человека с панцирем.
И приводит к субьективности оценок. Что в случае с научным экспериментом на мой взгляд не особо то и допустимо.
Скажите это научным статьям по психологии.
Я намекаю что это даже формально не определено.
Четкое формальное определение будет при попытке постановки эксперимента. Какой смысл в рамках дискуссии на хабре докапываться до точной формальной формулировки? Готов поспорить, что дальше слов это всё равно никуда не уйдет.
Не вижу в этом чего-то невозможного. Дайте мне исходники всего этого добра, финансирование для меня и команды, которую я найму для этой задачи, и я смогу сделать гибрид этих двух систем.
Думаю, вы это понимаете как-то по-другому, не так как я. Как раз ограничение возможных исходов делает эксперимент фальсифицируемым. Если вы проведете этот эксперимент и получите тот исход, которые не описан в рамках этих двух — вы опровергните его гипотезу.
Почему-то запуск зонда и его посадка на летящую комету вполне себе работает, хотя там невероятное количество того, что что-то может пойти не так, и у них всего одна попытка. Вы ведь не будете говорить, что какая-то соцсеть будет сложнее миссий наса?
Ответ прост. Фейсбуку просто-напросто пофиг на все эти конфиденциальные данные. Утверждать они могут другое, но приоритет у них явно не в этом. Так же как и с майкрософтом и эпплом.
Вообще-то он как раз предложил пример фальсификации. Достаточно найти хоть один случай, когда здоровый разумом человек тратит Х времени на что-то, в данном случае, на математику, и не может её понять — и гипотеза khim будет опровергнута.
Под простотой программирования я имею ввиду малое количество информации, которое требуется для того, чтобы описать его. Программирование основано на логике, а значит, зная некоторый минимальный набор фактов, можно остальное вывести самостоятельно, если на это будет желание. Нет противоречий и внутренней сложности.
Возьмите что-то более гуманитарное, для примера, экономику. Количество данных для составления правильной модели мира требуется колоссальное. Всё со всем взаимодействует, огромное количество необъективных факторов на всех уровнях, вроде жадности и страха. Всё настолько плохо, что многие люди всерьез верят в сильную гипотезу эффективного рынка.
Этого я и не утверждал, в общем-то.
Дело не в том, может кто-то конкретный написать лучше или не может.
Руляционная СУБД — это некоторым образом вещь в себе. Она доступна нам в виде интерфейса высокого уровня, плюс несколько ручек, которые можно крутить — всякие размеры кеша и подобное. У такого подхода есть некоторые ограничения. Например, иногда программист может составить лучший план для какого-то конкретного запроса, чем это делает сама субд. Он может косвенно влиять на выбор плана — например, через создание/удаление индекса, но это именно что косвенное влияние. Соответственно, крутые спецы по базам данных из-за этого в некотором роде похожи на шаманов — если тут ударить в бубен и там станцевать, то может пойти дождь, но это не точно.
Под database first подходе подразумевается вся бизнес-логика в виде хранимых процедур? Ну, это тоже антипаттерн.
Если нет, и вы имеете в виду куски чистого sql вперемешку с обычным кодом, то представьте следующее. Вам нужно отдать список чего-то по запросу, и в этом запросе может быть десяток различных параметров фильтрации. Представляете, насколько криво и нечитаемо будет смотреться конкатенация строк чистого sql запроса в таком контроллере?
Забавно. По форме вашего комментария можно сделать вывод, что вы со мной не согласны, тогда как по смыслу — полностью поддерживаете мои слова.
Представьте, если бы по http-апи приходили параметры запроса не в таком виде: {id: 1, name: «Joe», ...}, а в виде обычного текста «user with id 12, name Joe, ...» и вам надо было сначала его парсить, потом что-то с ним делать, потом обратно превращать в обычный текст и отдавать обратно. Да вы бы первый сказали «вы тут что, больные все собрались?» и уволились бы оттуда.
Или разметка сайта не тегами "\<html\>...\<body\>....\</body\>\<html\>" бы делалась, а текстом типа: «Документ с заголовком: название заголовка. Содержимое документа: блок такой-то с содержимым таким-то».
Но базы данных — это сложная тема, тут не любят изменений, а на первое место выходит надежность. Плюс уже полвека так работает, все привыкли. Но это не значит, что не существует лучшего пути. В конечном счете, сами базы данных не с текстом ведь работают, они у себя внутри парсят запросы на синтаксические деревья в пригодном для машинной обработки виде.
Огромное количество ОРМ придумано потому, что люди не хотят напрямую работать с чистым sql. Но эта практика изначально порочна, потому что в конечном счете надо трансформировать запрос обратно в «человеческий» язык, перед отправкой в базу данных, со всеми его ограничениями.
Аналогичности тут нет никакой. Пересадка головы — это замена устройства на аналогичное с тем же интерфейсом. То, о чем говорите вы — это как смешать днк человека и черепахи так, чтобы создать новый вид — человека с панцирем.
Четкое формальное определение будет при попытке постановки эксперимента. Какой смысл в рамках дискуссии на хабре докапываться до точной формальной формулировки? Готов поспорить, что дальше слов это всё равно никуда не уйдет.
Учителя же как-то отличают, кто сам работу написал, а кто списал. Кто учится, а кто бездельничает.
Почему-то запуск зонда и его посадка на летящую комету вполне себе работает, хотя там невероятное количество того, что что-то может пойти не так, и у них всего одна попытка. Вы ведь не будете говорить, что какая-то соцсеть будет сложнее миссий наса?
Ответ прост. Фейсбуку просто-напросто пофиг на все эти конфиденциальные данные. Утверждать они могут другое, но приоритет у них явно не в этом. Так же как и с майкрософтом и эпплом.
Но простота не означает легкость. Копать картошку лопатой тоже просто, но кто скажет, что это легко?
Под простотой программирования я имею ввиду малое количество информации, которое требуется для того, чтобы описать его. Программирование основано на логике, а значит, зная некоторый минимальный набор фактов, можно остальное вывести самостоятельно, если на это будет желание. Нет противоречий и внутренней сложности.
Возьмите что-то более гуманитарное, для примера, экономику. Количество данных для составления правильной модели мира требуется колоссальное. Всё со всем взаимодействует, огромное количество необъективных факторов на всех уровнях, вроде жадности и страха. Всё настолько плохо, что многие люди всерьез верят в сильную гипотезу эффективного рынка.