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

В контексте СУБД, обе вещи используются ровно для одного и того же — описания и передачи данных.

Фигня какая-то. В смысле на лету? Типа фигак и мы кроме продуктов торгуем ещё и смартфонами? А фронтенд к этому готов будет?

Можно (и нужно) и фронт универсально написать. В юлмарт погляди, например.

Фигня какая-то. В смысле на лету? Типа фигак и мы кроме продуктов торгуем ещё и смартфонами? А фронтенд к этому готов будет?

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

Можно (и нужно) и фронт универсально написать. В юлмарт погляди, например.

Но это точно не благодаря json

Но это точно не благодаря json

Нет, конечно. JSON один вариант только. XML, наследнование, EAV — другие

"

а монга она как-бэ конкретно на JSON документах специализируется.. поэтому я бы скорее брал Mongo + SQL нежели просто blob в таблице.. ибо что если например по свойствам поискать реализовывать придётся?

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

Ну, можно всё, но вот такие выкрутасы — это не ко мне. Я noSQL не люблю и посылаю в Ж...

ахаха

JSON файл, что-же ещё

все лучше и лучше

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

так монга индексирует документы, в чём проблемы?

Язык описания данных объектов, который НЕ ПОДДЕРЖИВАЕТ ООП вообще... Это надо было очень должно выдумывать, чтобы такое придумать.

это уже апогей, или дальше будет еще лучше?

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

да, дальше еще лучше

так монга индексирует документы, в чём проблемы?

в том, что ты решаешь проблему индексации вместо проблемы поиска, например

да, дальше еще лучше

Эт ты еще много пропустил

в том, что ты решаешь проблему индексации вместо проблемы поиска, например

а?!

а?!

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

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

Они не проверяют. Они "натягивают сову на глобус " и удивляются

тем что это менее гибкое решение нежели с присобаченным документом

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

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

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

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

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

спасибо, я умею читать

да, только вечно растущие query

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

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

хотите таблицы на лету создавать? нуну

все что угодно, лишь бы найти решение внутри любимого инструмента

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

все что угодно, лишь бы найти решение внутри любимого инструмента

конечно)) зачем перемещать определённые данные в noSQL, если всё можно сделать на SQL! будем натягивать проблему на SQL, всегда, везде, по любому поводу..

Я о том, что проблема сложных квери решаема.

Ага, отказом от сложных квери

делайте что хотите, как хотите)) мне вообще пофиг)

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

Ща тебя закидают памперсами использоваными. Ты покусился на святое. Я уже пытался двигать им такую идею.

Почему тут вечный срач?

А зачем мы еще тут сидим?

Почему тут вечный срач?

Покой нам только снится

Почему тут вечный срач?

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

Давайте предметно говорить. Вы назвали кейс, который может понадобится для администратора магазина (предположим) и будет не актуален для большинства пользователей -> для реального применения

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

Это в какой?

Я очень давно смотрю на монгу. Но у меня с неё печет (как разработчика). В большиснтве приложений она не нужна. Разруливать кучу вещей на уровне приложения тоже удовольствия мало.

Да для просто плоской модели любое документоориентированное хранилище подойдет (но я, конечно, евангелирую elasticsearch)

Я очень давно смотрю на монгу. Но у меня с неё печет (как разработчика). В большиснтве приложений она не нужна. Разруливать кучу вещей на уровне приложения тоже удовольствия мало.

монгу большинство использует не по назначению, а в данном случае она вполне может себя оправдать

- Почему мы не будем использовать этот инструмент? - У меня печет

Да для просто плоской модели любое документоориентированное хранилище подойдет (но я, конечно, евангелирую elasticsearch)

зачем elasticsearch, если есть SQL?! </sarcasm>

Пока вы срётесь, можно было всё по таблицам раскидать

Да для просто плоской модели любое документоориентированное хранилище подойдет (но я, конечно, евангелирую elasticsearch)

Ты еще кассандру предложи на жабе...

И будет срач

Пока вы срётесь, можно было всё по таблицам раскидать

зачем по таблицам то? в файлы всё, в файлы!

зачем по таблицам то? в файлы всё, в файлы!

В блокнот же

- Почему мы не будем использовать этот инструмент? - У меня печет

потому что в большинстве кейсов мы 1 - работаем со структурированными данными, у нас ЕСТЬ СХЕМА. а это значит, что скорее всего она укладывается в реляционную модель. (попробуйте с монгой нормально поработать в го, это очень больно) 2 - в случе монги мы усложняем код приложения. Это не круто. 3 - делать выборки в монге на самом деле то еще удовольствие, потому как стандартного языка может быть мало, а делать многие вещи, которые делают в реляционных субд уже десятилетиями вручную то еще удовольствие. лучше тереть боль от 1 бд, чем от 2х. Есть особоый кайф сопоставлять данные из 2х бд.

Помню тут кто то пару месяцев назад делал бд для хранения всяких электронных компонентов. И кртчал что у всех все разное.

потому что в большинстве кейсов мы 1 - работаем со структурированными данными, у нас ЕСТЬ СХЕМА. а это значит, что скорее всего она укладывается в реляционную модель. (попробуйте с монгой нормально поработать в го, это очень больно) 2 - в случе монги мы усложняем код приложения. Это не круто. 3 - делать выборки в монге на самом деле то еще удовольствие, потому как стандартного языка может быть мало, а делать многие вещи, которые делают в реляционных субд уже десятилетиями вручную то еще удовольствие. лучше тереть боль от 1 бд, чем от 2х. Есть особоый кайф сопоставлять данные из 2х бд.

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

потому что в большинстве кейсов мы 1 - работаем со структурированными данными, у нас ЕСТЬ СХЕМА. а это значит, что скорее всего она укладывается в реляционную модель. (попробуйте с монгой нормально поработать в го, это очень больно) 2 - в случе монги мы усложняем код приложения. Это не круто. 3 - делать выборки в монге на самом деле то еще удовольствие, потому как стандартного языка может быть мало, а делать многие вещи, которые делают в реляционных субд уже десятилетиями вручную то еще удовольствие. лучше тереть боль от 1 бд, чем от 2х. Есть особоый кайф сопоставлять данные из 2х бд.

https://docs.mongodb.com/manual/core/schema-validation/ для вас же сделали

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

скажи это стартапам,, которые берут ЖС везде и естественно монгу. ЖСОН ЖЕ!

скажи это стартапам,, которые берут ЖС везде и естественно монгу. ЖСОН ЖЕ!

Зачем мне кому то что то говорить то? Если стартап взлетит то получим тонну хомяков с криками "смари у них это работало и нам так нужно"

Хотлеось бы увидеть подход, который ты описал) Но, как сказал 1 чувак, стартапам не нужны инженеры. СТартапам нужны макаки, которые быстро реализуют фичи.

потому что в большинстве кейсов мы 1 - работаем со структурированными данными, у нас ЕСТЬ СХЕМА. а это значит, что скорее всего она укладывается в реляционную модель. (попробуйте с монгой нормально поработать в го, это очень больно) 2 - в случе монги мы усложняем код приложения. Это не круто. 3 - делать выборки в монге на самом деле то еще удовольствие, потому как стандартного языка может быть мало, а делать многие вещи, которые делают в реляционных субд уже десятилетиями вручную то еще удовольствие. лучше тереть боль от 1 бд, чем от 2х. Есть особоый кайф сопоставлять данные из 2х бд.

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

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

вы всё равно нормализуете эти данные, вы же с ними работаете.

Хотлеось бы увидеть подход, который ты описал) Но, как сказал 1 чувак, стартапам не нужны инженеры. СТартапам нужны макаки, которые быстро реализуют фичи.

Инженеры тоже быстро реализуют фичи. Причем эти фичи еще и работают. Проблема что им не хотят за это платить нормально

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

Не бывает продуктов с совершенно произвольными атрибутами

Это ваши сексуальные фантазии

вы всё равно нормализуете эти данные, вы же с ними работаете.

это динамические данные, которые выявляются во время выполнения. Они не известны во время запуска

вот я о том же. На примере магазина у вас всё равно унифицированный шаблон в который вы рендерите этот самый ТОВАР С ПРОИЗВОЛЬНЫМИ АТРИБУТАМИ.

это динамические данные, которые выявляются во время выполнения. Они не известны во время запуска

и как же ваш продукт вообще работает тогда?)

вы так или иначе ОПИСЫВАЕТЕ ВСЕ КЕЙСЫ КАК ОН МОЖЕТ РАБОТАТЬ

Данные выявляются во время выполнения.. ыыыы. Они из черной дыры НЕОЖИДАНО генерятся?

Данные выявляются во время выполнения.. ыыыы. Они из черной дыры НЕОЖИДАНО генерятся?

да да, из неё самой

да да, из неё самой

Срочно стройте генератор случайных чисел на этом принципе

ERROR: S client not available

Срочно стройте генератор случайных чисел на этом принципе

обязательно!

2018-07-01 12:11:23 [DEBUG] BlackHole has emitted 3 CAR products and 4 TOOTHBRUSH products

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

2018-07-01 12:11:23 [DEBUG] BlackHole has emitted 3 CAR products and 4 TOOTHBRUSH products

Emmited has BlackHoled products CAR 3 and TOOHBRUSH products 4

ПРо товары с неизвестными атрибутами конечно позабавило

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

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

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

ну так опиши такой кейс.

ну так опиши такой кейс.

ещё раз? да вы издеваетесь)) я пошёл делом заниматься

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

Все кейсы уже существовали в природе. То что вам кажется новым на самом деле есть обобщение нескольких уже старых.

А то что 99% разрабов не умеет нормализовать данные. Так это точно не новость

На мой взгляд в реальном приложении всё не ограничивается удобно писать и работать с данными. Давайте еще вспомним, что в монге нет транзакций (а в приложении будут критичные данные всегда). Затем вспомним, как мы ручками делаем то, что в мерзком SQL есть давно и внезапно оказывается, что сделать на реляционке всё менее больно.

Иначе всем бы хватало простого хранилища. И датацентры еще лет 50 бы не появились

На мой взгляд в реальном приложении всё не ограничивается удобно писать и работать с данными. Давайте еще вспомним, что в монге нет транзакций (а в приложении будут критичные данные всегда). Затем вспомним, как мы ручками делаем то, что в мерзком SQL есть давно и внезапно оказывается, что сделать на реляционке всё менее больно.

вы опять? я же сто тыщ раз уже упомянал, что монга не для критичных данных а для вариабельных документов, и вы опять мне это объясняете?))

в мире ПРИЛОЖЕНИЙ нет вариабельных данных. Структура будет всегда, супернейронку еще не изобрели.

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

в мире ПРИЛОЖЕНИЙ нет вариабельных данных. Структура будет всегда, супернейронку еще не изобрели.

Эээ уже даже рабочий код есть

И он работает :)

И нормализует любую динамическую хрень

Правда нафиг никому не нужен почему то.

На мой взгляд в реальном приложении всё не ограничивается удобно писать и работать с данными. Давайте еще вспомним, что в монге нет транзакций (а в приложении будут критичные данные всегда). Затем вспомним, как мы ручками делаем то, что в мерзком SQL есть давно и внезапно оказывается, что сделать на реляционке всё менее больно.

Зачем тебе многострочные транзакции в интернет-магазине?

Я открыл ваш проект из biography. Вёрстка едет на моём устройстве. В общем ясно))

Я открыл ваш проект из biography. Вёрстка едет на моём устройстве. В общем ясно))

какой проект?

fitcat.pro

cto @ landing page

Я открыл ваш проект из biography. Вёрстка едет на моём устройстве. В общем ясно))

на каком устройстве?

ноутбук

на телефоне всё хорошо, да

ноутбук

и что у тебя там поехало?

весь сайт в бок, и ваши хаотичные данные ?

весь сайт в бок, и ваши хаотичные данные ?

это какой у тебя браузер?

ширина страницы больше разрешения ноутбука, сдвигаю в бок и всё сдвигается