И пока там была 1 статья, угадай что показывала эта кнопка

Что?

Ну т.е у меня есть даже вариант, что она была неактивна

?)

Ну т.е у меня есть даже вариант, что она была неактивна

Нет, оно всегда возвращало одну единственную статью.

Тоже логично ведь

Нет, оно всегда возвращало одну единственную статью.

Прикинь возвращало бы разные ?

Нет, оно всегда возвращало одну единственную статью.

А ты че не спишь то

Прикинь возвращало бы разные ?

Это было бы шикарно

Поставил, потыкал - вот и Вики готова

А ты че не спишь то

Выходные, лето

Поставил, потыкал - вот и Вики готова

Можно автокликер приделать. Что бы побольше

Теперь да. Витуху припаял?

Теперь да. Витуху припаял?

Это до jtag

Это до jtag

А чего сразу не распаял на плату разъем?

А чего сразу не распаял на плату разъем?

Разьем денег стоит. Причем не гуманных.

А кусок витухи бесплатно

Разьем денег стоит. Причем не гуманных.

Хех, думал они не дорого обходятся.

Хех, думал они не дорого обходятся.

Там не китайский шаг

Жа и нафиг он там ради одной прошивки. Оно по радио умеет обновлять

Жа и нафиг он там ради одной прошивки. Оно по радио умеет обновлять

Ну норм)

Всем привет. Подскажите, как правельно спроектировать структуру БД для продаж различных товаров и услуг. При этом, товары и услуги должны входить в тариф. То есть покупаться будет не отдельный товар, а тариф, который будет состоять из различных товаров. Не пойму как связать таблицу товары, непосредственно с самими товарами, ведь они могут быть в нескольких таблицах. Напривет, некие наборы данных, это будет первая таблица, а различный функционал сайта, это будет вторая таблица. И вот как добавить в таблицу тарифу, два товара из разных таблиц?

Я правильно понял что у тебя есть таблица с товарами, таблица с услугами структура которой отличается от товаров и таблица которая использует как и товары так и услуги? Так?

скорее вот этот https://t.me/postgis

какие люди)

какие люди)

Хехехе)

Всем привет. Подскажите, как правельно спроектировать структуру БД для продаж различных товаров и услуг. При этом, товары и услуги должны входить в тариф. То есть покупаться будет не отдельный товар, а тариф, который будет состоять из различных товаров. Не пойму как связать таблицу товары, непосредственно с самими товарами, ведь они могут быть в нескольких таблицах. Напривет, некие наборы данных, это будет первая таблица, а различный функционал сайта, это будет вторая таблица. И вот как добавить в таблицу тарифу, два товара из разных таблиц?

вангую eav

Всем привет. Подскажите, как правельно спроектировать структуру БД для продаж различных товаров и услуг. При этом, товары и услуги должны входить в тариф. То есть покупаться будет не отдельный товар, а тариф, который будет состоять из различных товаров. Не пойму как связать таблицу товары, непосредственно с самими товарами, ведь они могут быть в нескольких таблицах. Напривет, некие наборы данных, это будет первая таблица, а различный функционал сайта, это будет вторая таблица. И вот как добавить в таблицу тарифу, два товара из разных таблиц?

о какой бд вообще идёт речь?

о какой бд вообще идёт речь?

Реляционная

Реляционная

SQL? ну тогда читайте про "relations" и как их моделируют

foreign key, все дела

Чё за тип

Вопрос прочитай нормально

Вопрос прочитай нормально

ничего себе, пытаешься человеку помочь а он тебе ещё и грубит...

ничего себе, пытаешься человеку помочь а он тебе ещё и грубит...

Помощи нет от вас, сударь

Помощи нет от вас, сударь

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

Всем привет. Подскажите, как правельно спроектировать структуру БД для продаж различных товаров и услуг. При этом, товары и услуги должны входить в тариф. То есть покупаться будет не отдельный товар, а тариф, который будет состоять из различных товаров. Не пойму как связать таблицу товары, непосредственно с самими товарами, ведь они могут быть в нескольких таблицах. Напривет, некие наборы данных, это будет первая таблица, а различный функционал сайта, это будет вторая таблица. И вот как добавить в таблицу тарифу, два товара из разных таблиц?

Почему же товары должны быть в нескольких таблицах?

Помощи нет от вас, сударь

А ты хотел готовый скрипт?

вангую eav

На обязательно, можно просто наследование

Походу набег троллей продолжается

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

Кто тебе хамил то? Ты не додумывай, чего не было, и все будет ок.

Кто тебе хамил то? Ты не додумывай, чего не было, и все будет ок.

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

ну нахер таким людям помогать..

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

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

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

бывает)

ну нахер таким людям помогать..

Но ты тоже не горячись, :)

Помощи нет от вас, сударь

Почему товары должны быть в Разных ТАБЛИЦАХ?

Почему товары должны быть в Разных ТАБЛИЦАХ?

Потому что структура у различных товаров, может кардинально отличаться. У одного могут быть поля 1 2 3, а у другого a b c

Потому что структура у различных товаров, может кардинально отличаться. У одного могут быть поля 1 2 3, а у другого a b c

Наследование это все лечит.

Наследование это все лечит.

Или EAV. Он тоже лечит.

или попробовать что-то документо ориентированное ?

или попробовать что-то документо ориентированное ?

Документоориентированное - это хрень какая-то, это не про проектирование РБД.

Документоориентированное - это хрень какая-то, это не про проектирование РБД.

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

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

Это изврат.

Это изврат.

поясни

поясни

Для довольно простой задачи ты предлагаешь применить сразу 2 субд

Если уж так нужно что-то хранить в json на манер монго - то это и постгрес умеет

Для довольно простой задачи ты предлагаешь применить сразу 2 субд

ну это сейчас она простая, а когда добавится ещё 3й вид продукта то.. сами понимаете.. это всё конечно зависит от конкретной проблематики..

Если уж так нужно что-то хранить в json на манер монго - то это и постгрес умеет

я вот кстати с postgres никогда не работал, она с документами так-же работает как и Mongo? Индексация, все дела

я вот кстати с postgres никогда не работал, она с документами так-же работает как и Mongo? Индексация, все дела

Ну не как монга.

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

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

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

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

Так в пг тоже можно прям json документ хранить, и индексация есть. Синтаксис при работе с этим просто на монгу не похож

ERROR: S client not available

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

SQL не в любой проблеме прокатит.. или ты реально хочешь 10 таблиц наплодить или 1 огромнейшую, вместо того чтоб вариабельные свойства отложить в другое месть? с чего кстати такое эмоцианальное восприятие noSQL?))

я вот кстати с postgres никогда не работал, она с документами так-же работает как и Mongo? Индексация, все дела

Ты понятие "документ" определи для начала.

Ты понятие "документ" определи для начала.

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

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

BLOB в таблице никто и не рекомендует (я по крайней мере).

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

XML файл. Текстовый файл. НЕТЕкстовый файл...

XML файл. Текстовый файл. НЕТЕкстовый файл...

XML то тут причём?

SQL не в любой проблеме прокатит.. или ты реально хочешь 10 таблиц наплодить или 1 огромнейшую, вместо того чтоб вариабельные свойства отложить в другое месть? с чего кстати такое эмоцианальное восприятие noSQL?))

Расскажи нам, где НЕ прокатит...

XML то тут причём?

Многие NoSQL его умеют и любят.

Расскажи нам, где НЕ прокатит...

Ладно, это всё уже дешёвый трёп пошёл, автору вопроса это не поможет.

Расскажи нам, где НЕ прокатит...

так вот же, уже пояснил... либо 1 огромная таблица с множеством свойств, либо несколько таблиц разной структурой, либо свойства в JSON в отдельном месте, а в SQL только базовые данные

так вот же, уже пояснил... либо 1 огромная таблица с множеством свойств, либо несколько таблиц разной структурой, либо свойства в JSON в отдельном месте, а в SQL только базовые данные

Чем тебя не устраивает несколько таблиц с разной структурой?

Чем тебя не устраивает несколько таблиц с разной структурой?

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

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

Про остальные варианты я ничего не могу сказать, поскольку первый не понял, а третий приемлим только если СУБД умеет JSON индексировать. К тому же JSON обладает достаточно бедными выразительными возможностями в части поддерживаемых типов данных и их расширений, так что я бы предпочёл XML, больше СУБД поддерживают, и есть XMLSchema

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

JOIN 10 ти таблиц ничего сложного не представляет.

Про остальные варианты я ничего не могу сказать, поскольку первый не понял, а третий приемлим только если СУБД умеет JSON индексировать. К тому же JSON обладает достаточно бедными выразительными возможностями в части поддерживаемых типов данных и их расширений, так что я бы предпочёл XML, больше СУБД поддерживают, и есть XMLSchema

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

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

Про "присобаченные документы" я тоже в общем говорить отказываюсь.

JOIN 10 ти таблиц ничего сложного не представляет.

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

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

Я тоже, но если сравнивать XML и JSON , последний явно проигрывает.

Я тоже, но если сравнивать XML и JSON , последний явно проигрывает.

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

Хотя, может я и не прав, полагая, что JScript — ООП язык.

с ассоциированным документом можно динамически создавать на лету новые типы продуктов, с разными таблицами это будет "грязнее", ибо придётся динамические таблицы плодить а это уже никуда не годится

с ассоциированным документом можно динамически создавать на лету новые типы продуктов, с разными таблицами это будет "грязнее", ибо придётся динамические таблицы плодить а это уже никуда не годится

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

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

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

с ассоциированным документом можно динамически создавать на лету новые типы продуктов, с разными таблицами это будет "грязнее", ибо придётся динамические таблицы плодить а это уже никуда не годится

Но зачем, есть EAV!

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

Это тебе так кажется...

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

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

Это тебе так кажется...

ну да ну да

ну да ну да

Я только правду говорю..

Я только правду говорю..

"правду" без аргументации))

но, лучше не надо, только спора XML vs JSON нам здесь ещё не хватало