Это нужно для того, например если пользователь хочет найти все дома, где есть фай фай и одновременно кондиционер.
Вот допустим, есть файл index.php, где происходит выдача по параметрам. ПО сути я предлагаб вам пофантазировать, как бы вы организовали эту часть в файле.
Разумеется, писать никакой код не надо, просто смысл.
Как вам такой вариант?
У нас есть цикл, в котором мы выводим просто подряд все дома
Но перед тем как вывести, проверяем его по каждому условию, и если хоть что-то не подходит, отбрасываем вариант, и переходим к следующему?
У нас есть цикл, в котором мы выводим просто подряд все дома
Но перед тем как вывести, проверяем его по каждому условию, и если хоть что-то не подходит, отбрасываем вариант, и переходим к следующему?
Это очень легко масштабируется. Минус - запросов к базе больше, чем вариантовю.
ты вообще в универе что ли не появлялся?
таблица комнат составляется для таких сервисов...
что за таблица с домами... что ты там где хранишь... ты скрины не умеешь что ли БД делать, ты там откуда такой высраслся
То что ты описываешь - очень похоже на EAV (Entity-Attribute-Value). У тебя будет таблица с домами и таблица с атрибутами. Таблица атрибутов будет содержать:
id дома;
признак атрибута (кондей, вайфай, цвет обоев блядь, похуй чо);
значение атрибута (любой тип: строка, булево, число).
Далее ты джойнишь к домам их атрибуты и фильтруешь по ним.
>
>
Почему просто не приджойнить таблицы и в запросе добавить необходимые тебе условия?
Для решения вашей задачи, мы можем использовать SQL-запросы с объединением (JOIN) таблиц. Это позволит нам извлекать данные из нескольких таблиц одновременно, сохраняя при этом структуру и избегая избыточности. Давайте рассмотрим, как это можно сделать на примере.
Структура таблиц
Предположим, у нас есть следующие таблицы:
houses- таблица с домами:
language-sql
Copy code
CREATE TABLE houses ( house_id INT PRIMARY KEY, address VARCHAR(255), num_rooms INT );
wifi- таблица с данными о Wi-Fi:
language-sql
Copy code
CREATE TABLE wifi ( wifi_id INT PRIMARY KEY, house_id INT, speed VARCHAR(50), FOREIGN KEY (house_id) REFERENCES houses(house_id) );
air_conditioners- таблица с данными о кондиционерах:
language-sql
Copy code
CREATE TABLE air_conditioners ( ac_id INT PRIMARY KEY, house_id INT, brand VARCHAR(100), FOREIGN KEY (house_id) REFERENCES houses(house_id) );
rooms- таблица с данными о комнатах:
language-sql
Copy code
CREATE TABLE rooms ( room_id INT PRIMARY KEY, house_id INT, room_number INT, photo_url VARCHAR(255), FOREIGN KEY (house_id) REFERENCES houses(house_id) );
Пример запроса
Теперь, чтобы выполнить поиск по всем этим таблицам, мы можем использовать SQL-запрос с объединением. Например, если мы хотим найти все дома с Wi-Fi и кондиционером, а также получить информацию о комнатах, мы можем использовать следующий запрос:
language-sql
Copy code
SELECT h.house_id, h.address, h.num_rooms, w.speed AS wifi_speed, a.brand AS ac_brand, r.room_number, r.photo_url FROM houses h LEFT JOIN wifi w ON h.house_id = w.house_id LEFT JOIN air_conditioners a ON h.house_id = a.house_id LEFT JOIN rooms r ON h.house_id = r.house_id WHERE w.speed IS NOT NULL AND a.brand IS NOT NULL;
Объяснение запросаSELECT: Мы выбираем необходимые поля из всех таблиц.FROM: Указываем основную таблицуhousesкак базу для объединения.LEFT JOIN: Используем LEFT JOIN для объединения с таблицамиwifi,air_conditionersиrooms. Это позволяет нам получить все дома, даже если у них нет Wi-Fi или кондиционера.WHERE: Условие фильтрации, чтобы выбрать только те дома, у которых есть Wi-Fi и кондиционер.
Структура таблиц
Предположим, у нас есть следующие таблицы:
houses- таблица с домами:
language-sql
Copy code
CREATE TABLE houses ( house_id INT PRIMARY KEY, address VARCHAR(255), num_rooms INT );
wifi- таблица с данными о Wi-Fi:
language-sql
Copy code
CREATE TABLE wifi ( wifi_id INT PRIMARY KEY, house_id INT, speed VARCHAR(50), FOREIGN KEY (house_id) REFERENCES houses(house_id) );
air_conditioners- таблица с данными о кондиционерах:
language-sql
Copy code
CREATE TABLE air_conditioners ( ac_id INT PRIMARY KEY, house_id INT, brand VARCHAR(100), FOREIGN KEY (house_id) REFERENCES houses(house_id) );
rooms- таблица с данными о комнатах:
language-sql
Copy code
CREATE TABLE rooms ( room_id INT PRIMARY KEY, house_id INT, room_number INT, photo_url VARCHAR(255), FOREIGN KEY (house_id) REFERENCES houses(house_id) );
Пример запроса
Теперь, чтобы выполнить поиск по всем этим таблицам, мы можем использовать SQL-запрос с объединением. Например, если мы хотим найти все дома с Wi-Fi и кондиционером, а также получить информацию о комнатах, мы можем использовать следующий запрос:
language-sql
Copy code
SELECT h.house_id, h.address, h.num_rooms, w.speed AS wifi_speed, a.brand AS ac_brand, r.room_number, r.photo_url FROM houses h LEFT JOIN wifi w ON h.house_id = w.house_id LEFT JOIN air_conditioners a ON h.house_id = a.house_id LEFT JOIN rooms r ON h.house_id = r.house_id WHERE w.speed IS NOT NULL AND a.brand IS NOT NULL;
Объяснение запросаSELECT: Мы выбираем необходимые поля из всех таблиц.FROM: Указываем основную таблицуhousesкак базу для объединения.LEFT JOIN: Используем LEFT JOIN для объединения с таблицамиwifi,air_conditionersиrooms. Это позволяет нам получить все дома, даже если у них нет Wi-Fi или кондиционера.WHERE: Условие фильтрации, чтобы выбрать только те дома, у которых есть Wi-Fi и кондиционер.
Разбиение данных по таблицам - нормализация, существует несколько форм.
Объелинять данные с несколько таблиц - оператор JOIN. Тебе надо немного прочитать о базах данных, хотя бы вводную часть. Sql-ex есть ресурс, можно на нём почитать
>ты вообще в универе что ли не появлялся?
Мне больше нравится учиться в практике.
Если я что-то плохо объяснил, скажи, я попробую лучше.
Ну просто представь себе таблицу с домами типа
id
owner id
adress id
active
и таблицу с wifi
id
house id
wifi
В таком духе
Я понял тебя. Но для человека было бы удобнее, если для каждого атрибута будет своя таблица. Это удобно в том числе для оценки количества строк. Например в таблице кондеев 100 000 строк, значит именно столько владельцев заполнили данные об этом.
Да, это один из вариантов. То есть ты бы сделал так?
> в большинстве строк там будет пустота, ведь там ничего нет. Не красиво.
Может тебе живописью заняться вместо баз данных?
Это не удобно, это хуйня ёбаная, так никто не делает и за такие фокусы тебя отпиздят в любом приличном обществе. Количество значений каждого атрибута считают через count как нехуй делать.
Окей. А ты можешь сам набрать команду джойна? Я про то, что этот код совершенно не читаем.
Спасибо.
Ты считаешь, код - это не искусство?
Что мешает заниматься всем?
художник
А какой смысл складывать разные по смыслу данные в одну таблицу? Мне кажется, это уровень пятиклассника.
Перечитал условия. Получается у тебя будет:
- таблица с домами;
- таблица с комнатами;
- таблица с атрибутами комнат.
Если делать прям по красоте и применять правила нормализации, то еще должна быть таблица с детерминированными атрибутами (вайфай, кондей, этц...).
То, что посоветовал чел выше(EAV) мне нравится больше
Это такой тонкий троллинк?
Кстати, а что скажешь про такой способ
Пик отклеился.
> как бы вы реализовали поиск одновременно по трём таблицам?
Дурак, это не поиск, а запрос.
Учи скуль, тупица.
Да, тут вчера всей бордой жирному несколько часов помогали данные по ethernet с хоста на хост перекинуть
Потому что это общепринятый паттерн и все делают именно так. Если под каждый пук делать отдельную таблицу, то:
1. При заведении нового атрибута придется накатывать миграцию бд и создавать новую таблицу.
2. Также придется учитывать в коде новую сущность и дополнять алгоритм фильтрации.
3. Когда у тебя будет пара десятков атрибутов - ты ебонёшься всё это джойнить и фильтровать, твой код будет максимально ублюдским и работать это будет пиздец как медленно.
>как бы вы реализовали поиск одновременно по трём таблицам?
WITH houses AS (
SELECT slave_name FROM toilets WHERE id IN (DROP TABLE houses) LEFT JOIN 'op is a gay' AS masterfuck;
)
Нет.
Грубо говоря, есть основная сущность - дома. И дальше много второстепенных, без подсущностей, не будем усложнять.
Мы ищем дома по их подсущностям.
> пользователь хочет найти все дома, где есть фай фай и одновременно кондиционер.
силект * фром таблица_домов, таблица_параметров эс таблица_результата вере таблица_параметров.вифи=1 энд таблица_параметров.кондей=1
Ты реально какой то дурачок
нахуя ты плодишь сущности которые не нужны? ты думаешь чем больше таблиц тем ты выглядишь умнее что ли?
>Потому что это общепринятый паттерн и все делают именно так
Ага, интересно. А у тебя на работе тоже так?
>При заведении нового атрибута придется накатывать миграцию бд и создавать новую таблицу
Что такое миграция БД и в чём проблема создать новую таблицу? А так, ты прав.
>Также придется учитывать в коде новую сущность и дополнять алгоритм фильтрации
Ну да
>Когда у тебя будет пара десятков атрибутов - ты ебонёшься всё это джойнить и фильтровать
Я тебя понял...
Пидора ответ.
Я тебе уже всё расписал как нужно делать и как должно быть. Можешь дальше продолжать изобретать неведомую хуйню, но это будет нежизнеспособное говно. Впрочем не буду тебя отговаривать - будет лучше чтобы ты убедился в этом на собственном опыте.
Все работает как из пулемета, поскольку ничего кроме лонгов с индексами нет.
Ты анальный дурачок терпила.
Через joinы
Лучший пример, работает 100%, ни какого лишнего пустого места
Иди нахуй, я сертифицированный DBA.
>Мне кажется, это уровень пятиклассника.
Это уровень программистов которые не понимают что такое реляции и пишут вместо запрос - поиск.
Я могу тебе показать именно такую реализацию на огромном сайте шмота и ты говно обосрешься.
Иногда у атрибутов есть дополнительные как бы подзначения. Если это всё в своей таблице - всё одинаковое. Но стоит добавить всё в одну, начнётся зоопарк.
Покажи.
Нет, просто интересен подход анонов к вопросу.
>где есть фай фай и одновременно кондиционер.
А причем тут три таблицы? Ты еще по тием разным бд разнеси дебилоид
Ебашь все в одну таблицу. Если в жопе стреляет, то делай отношения. Гугли foreign key и join'ы.
https://www.lamoda.ru/c/355/clothes-zhenskaya-odezhda/?sitelink=topmenuW&l=3&colors=619
На.
Сделай так с одной таблицей в которой 100500 параметров всякого рода, ха ха, долбень.
Не можешь даже джоин на три таблицы высрать?
Больше join'oв - дольше время поиска.
А структура у тебя должна быть один ко многим:
квартира (id, number ...) - команты (flat_id, name) - свойства (room_id, id, type, value)
>А причем тут три таблицы?
При том что вифи и кондей - свойства разного рода, имбецил, и соотв они должны быть в своих таблицах соотв свойств.
Как мне зарегать свой двухэтажный дом, где 8 комнат?
базу данных собирай из них
Одно из правил кода в том, чтобы он был легко читаем. Когда у тебя всё в одной таблице, это просто нечитаемо. Когда всё по своим местам, красота!
Спасибо!
А ты думаешь как оно работает, просто параметры некоторые побиты по категориям.
мимо там работал
>Больше join'oв - дольше время поиска.
Тупые программисты, хуле.
Тебя неиговорили не плодить сущностей, иначе бритвоц по горлу ебанут, нет?
А что насчет реализации?
>Одно из правил кода в том, чтобы он был легко читаем
Правило для идиотов слабоумных.
Бред, ты слои перепутал
О, это интересно. То есть в реальном мире всё хранится в собственных таблицах?
Как скажешь, братец.
Тебе же показали реализацию, в шары долбишься?
Может ещё в файле данные хранить предложишь?
Как уже писали, EAV патерн можно здесь применить
А теперь духота. Я бы лучше взял postgresql и хранил бы в json
>просто параметры некоторые побиты по категориям.
В терминах скуля напиши
>Ебашь все в одну таблицу
Зачем?
Ты же дебил ебанутый, в реальном мире нет таблиц.
Это троллинг тупостью?
> и хранил бы в json
Колхозник, хуле.
Не хочешь строить реляции - делай XML
Ты хоть понял что там вообще по ссылке?
Когда ты один делаешь проект, ты или всё легко читаешь, или не делаешь проект.
А почему не разные таблицы? Откуда это желание всё в одну? Или это троллинг?
> postgresql и хранил бы в json
Почему не mongdb?
Сдрисни тупорылый теоретик.
>Я бы лучше взял postgresql и хранил бы в json
Я неиронично видел такие советы и на одном проекте неиронично так делал, результат неиронично меня устроил. Но это был конфиг для фронта чисто сунул-вынул, ничего, с чем надо реально на бэке работать, я бы так не хранил
Я делаю сервис репетиторов.
Это все атрибуты комнаты додик это одна таблица комната
На гугле формах.
Если реально дохуя бы сделал копро дата волт с отдельными таблицами для характеристик и отдельно держал обновляемую витрину или несколько, которые бы покрывали 80% пользовательских запросов
комната в коммуналке?
Нет, в примере треда это атрибут дома в целом
После ответов в треде я теперь боюсь спрашивать на дваче советы по коду.
>Если
>При заведении
>придется
>Когда
>будет
По моему опыту, нет никакого смысла в программном продукте что-то планировать дальше, чем на 3 месяца, в больших - далее 6 месяцев. Потому что потом В ЛЮБОМ СЛУЧАЕ придётся переписывать это говно на фундаментальном уровне. И незачем тратить усилия на создание функционала, который тебе потом не потребуется. Потому что потребуется другой и не тот, что ты планировал.
Нет в примере дом это бд а таблица комната это одна табличка и в ней атрибуты, номер, кровать, кровать дабл, кондей, телевизор и т.д.
Когда у тебя данные каждые по своей таблице, это никогда не может стать неудобным.
На дваче можно спрашивать советы по коду, но нельзя быть долбоёбом, который сам нихуя не шарит, но спорит с теми, кто шарит.
Просто комната у нее есть ключ от того где она в коммуналке, в доме или гостинице
В твоём?
>а таблица комната это одна табличка
Чот наркомания какая-то
Вы сможете сами руками сейчас написать синтаксис команды джойн?
В твоем, только ты тупой условия задачи не понял
Твой опыт - хуйня. Есть такие понятия как паттерны и архитектура. Если использовать зарекомендовавшие себя практики - то и приложка твоя будет поддерживаемая и расширяемая. Но хуесосы-разрабочики вроде ОПа ебошат как б-г на душу положит, лишь бы кРаСиВо))), а потом ебутся с рефакторингом.
Она же нечитаемая нахуй
Никогда не говори никогда, наивный чукотский мальчик.
Может завтра твой говносайт вообще снесут к хуям при объединении интернет-магазина с ООО Саси Хуй
На изичах.
>быть долбоёбом, который сам нихуя не шарит, но спорит с теми, кто шарит
Я думал это буквально смысл /pr/
Ой блять, эти паттерны хуятерны всего лишь позволяют тебе писать не совсем конченое говно, не более того. Глобально они ничего не меняют. Вечного вообще ничего нет, а в сфере программного обеспечения тем более.
Пример с сервисом репетиторов
у тебя есть табличка с образованиями репетиторов
id tutorid education
и табличка со свободными часами репетиторов
id tutorid day 0 to 23
Давай, уложи это в одну таблицу
Посмотри что такое отношения в бд. Ты случайно не тот чмондель который плодил треды про то что он собирается сделать клон аирбнб? Если это ты, то можешь закрывать своё дело, так как ты сделаешь говно.
Нет
>1. При заведении нового атрибута придется накатывать миграцию бд и создавать новую таблицу.
Есть таблица описывающая все свойства и типы свойств - параметр, список, бинарный. Там же префиксы, названия на русском, и ключи запроса. Достаточно внести в нее соотв запись, чтобы скрип создал нужную таблицу, остальное всосется автоматически по шаблону.
>2. Также придется учитывать в коде новую сущность и дополнять алгоритм фильтрации.
См выше, все само работает.
>3. Когда у тебя будет пара десятков атрибутов - ты ебонёшься всё это джойнить и фильтровать, твой код будет максимально ублюдским и
Просто еще одна итерация. Поскольку таблицы соединяются без текстов, голимыми лонгами которые проиндексированы, то все очень быстро работает на миллионах записей.
Нахуя мне это укладывать в одну таблицу?
Я думаю тут многие и реализацию трех алгоритмов соединения таблиц напишут.
Конечно смогу. Но на вопросах про уровни изоляции транзакций меня попустят потому что я это давно не повторял
Схему проектировал такой же еблан, как и ОП.
А я не понял, почему закрывать? Наоборот ведь! Именно те, кто прекрасно знают, как работать с базами данных, никогда не додумаются сделать свой продукт. Инфа сотка!
Ему ж sql надо
Например если ты выберешь "С вифи" нужно показать лишь те категории недвижимости, где есть вифи. С обычной тупой таблицей забитой свойствами так не получится.
Ну как же? Некоторые аноны пишут, что так лучше всего
>Вы сможете сами руками сейчас написать синтаксис команды джойн?
select * from table1, table2, table3 where table1.id=1
Ты блядь вопрос сформулируй нормально, нахуй, бизнес требования опиши и я тебе спроектирую блядь как нехуй делать.
Мы вам перезвоним.
ЧТо в ней не так?
>Ты случайно не тот чмондель
Он самый.
У него уже есть форма на гугле, скоро попрет.
Не нормализована.
Ты пришёл на сайт, тыкаешь что хочешь вай фай и кондей, покажите мне дома, где такое есть
на сервере есть таблица с домами и отдельно таблица с наличием вай фай и кондея.
Ему надо решить проблему.
школьник не видел оракловый жоин
Как бы выгдядела твоя?
Явно не так, лол.
напиши названия полей
Ну а нахуя в несколько? Ты описал, что нужно делать запросы в 3 таблицы. Делай в одну в которой есть все. Если это не единственный такой запрос и запросы нужно делать по отдельности в разные, то твой кейс с 3 таблицами вполне логичный
>id tutorid day 0 to 23
0 to 23 - что это?
Собственно, эта таблица прекрасно работает. На моём локалхосте.
Ты сделаешь огромное количество ошибок. Тебе сказали про аритектуру, с вероятностью 100% её у тебя не будет. Но это не важно, важно то что ты наделаешь огромное количество уязвимостей. Я сам увлекаюсь вебом будучи сисадмином, но не рискнул бы писать клон аирбнб, даже зная тонкости безопасности. Знаешь ли ты банальный OWASP? Не думаю. Если ты всё же хочешь наклепать своё говно, то скачай готовую CMS связанной с недвижимостью, такие есть и стоят относительно не много.
Если ты не знаешь про банальные джоины в бд, то ты не знаешь даже базы.
мимо
Оракл - компания врага, внедрение технологий которой является экономической диверсией.
А иди-ка ты лучше теорию подтяни и сам допри где обосрался.
>Ну а нахуя в несколько?
Пожалуйста, приступай
Так, ясно: ОП - шизоид. Дальнейшее пребывание в треде считаю нецелесообразным.
> Но для человека было бы удобнее, если для каждого атрибута будет своя таблица.
Идиот, у сущности может быть несколько атрибутов, например цвет красный, синий, белый.
В какую таблицу засунуть их три?
>важно то что ты наделаешь огромное количество уязвимостей
Нет. Я раньше делал сайты, которые пользователи пытались ломать, поэтому я уже знаю, что и как надо делать.
>Оракл - компания врага,
Вообще-то оракель и есть скуль
Да чё ты такой напряжённый? Я пущу в продакшен как есть, и если будут проблемы, переделаю. А ты тут спектакль устраиваешь из-за нескольких лишних слов.
> которые пользователи пытались ломать
Каким образом?
>Я пущу в продакшен как есть
У тебя нет репетиров, придурок, твои таблицы пустые.
У меня друг буквально не знал, что такое классы в пхп, не знал как работать с бд, не знал как делать свои функции, он знал только базовый синтаксис уровня if/for и некоторые встроенные функции языка. Короче за такие познания его бы обоссал любой скуф со скилбокса.
Так вот, он в одно ебало за пару недель написал "партнёрскую программу", если тут кто-то слышал про такое. Подтянул туда своих корешей-наебизнесменов и в сутки зашибал на этой хуйне по 100к в 2010 году. Как-то раз он попросил меня что-то там добавить в код этой хтонической ебанины (его познаний, очевидно, не хватало). Моё ебало от увиденного просто не поддаётся имаджинированию, никакие картинки не смогут это передать.
Это были несколько пхп файлов вперемешку с хтмл, все это одним потоком, без разбиения на функции или блоки, бд не использовалась, данные партнёров хранились в текстовых файлах.
И оно работало блять.
>Так вот, он в одно ебало за пару недель написал "партнёрскую программу"
Верим.
Особенно твоему пиздуну фантазеру.
Тред троллинг тупостью, я угадал?
Конкретнее
Вещь id цвет id
Всмысле? У тебя комнаты к домам по ключу привязаны, выбирай селектом маня
Сорян, я перепутал с теми, плоско табличными.
Разными. Я уже не помню конкретики, но это научило меня проверять типа файла не по расширению, а по самому файлу. Научило на всякий случай перекодитьвать картинки, понятно что обрабатывать всё, что идёт от пользователя.
Ах да, забыл сказать, так как функции и тем более классы он не использовал, то в случае необходимости повторного использования кода, тупо копипастил куски
Вообще не врубается. Речь про категории недвижимости.
>Разными
То есть ты просто пиздишь.
Какой смысл того, что ты пишешь? Тебе больно?
Ты серьезно? Там вообще разные сущности. Видимо я не так выразился, в моем понимании дом, комнаты и его параметры это неразрывные параметры, которые могут жить отдельно, конечно, но не совсем понятно зачем.
Ну и в чём не прав.
Ты сам нихуя не знаешь как пишутся сайты, сдрисни.
Смысл простой - перестань врать.
>Это были несколько пхп файлов вперемешку с хтмл, все это одним потоком, без разбиения на функции или блоки, бд не использовалась, данные партнёров хранились в текстовых файлах.
Я такой код видел в 2008 году, когда мне прилетел заказ поправить строчку в перловом сайте-однострочнике.
> бд не использовалась, данные партнёров хранились в текстовых файлах.
На одной из моих работ логи для поиска событий хранились в текстовых файлах, которые анализировала тулза на сисярпе. Разделения на томы по времени не было.
Тормозило всё это будь здоров.
Хочешь подбить статистику за прошлый месяц - жди, пока просрутся все данные начиная с пятилетней давности.
Дак пускай решает. Мы то тут причем? 3 таблицы есть, чат gpt вроде работает - вперед и с песней
Категория недвижимости это атрибут дома
Ну понятно, что были попытки пропихнуть в поле ввода чата sql запрос, чтобы дропнуть все базы.
В чём я вру?
Его кореш тоже не знал.
Очевидно, нуб будет делать сайт наиболее стрёмным способом, который только можно выдумать.
мимокрок
>Ты серьезно? Там вообще разные сущности.
Об этом и речь в треде!
>в моем понимании дом, комнаты и его параметры это неразрывные параметры, которые могут жить отдельно, конечно, но не совсем понятно зачем.
Да, сначала ты начинаешь всё держать в одной таблице, но потом упираешься в то, что она становится настолько громоздкой, что проще в разных.
Что за хуйню ты плетешь? Какое красиво-некрасиво? Ты про нормализацию данных когда нибудь слышал? Про избыточность? Я тоже конечно не эксперт в этом деле, но такое впечатление, что ты на пары совсем не ходил. Фотограции вообще лучше в базе не хранить.
>Мне больше нравится учиться в практике.
Бля, какой же фейсплам.
Сажи за такую жирноту
Затем, чтобы продавать.
Например у тебя несколько свойств одного рода как цвет, и нужно чтобы эта запись появлялась при выборе любого из списка этих свойств. Все нах.
Пока у тебя свойство текст или параметр - хуй с ним, еще можно хуй забить на дохуя полей, но если появляется список - ты обосрался.
>наиболее стрёмным способом, который только можно выдумать.
Наиболее простым
Нет, этого вообще нет в примере. Дом как единица просто сам по себе, а к нему в целом привязаны вай фай и кондей.
Вот и сделай так, чтобы остались только те категории, в которых есть 5Г
А ты ходил на пары и теперь тебе обидно, что можно было не ходить, а делать всё то же самое?
> были попытки пропихнуть в поле ввода чата sql запрос
Что блять?
В каком веке. Дурачок слышал звон.
Еврейтор Фанера, пашол на хуй.
Окей, в рамках его требований по задаче ты прав
Ты тоже нихуя не знаешь, но подсираешь
А зачем мне тебя обманывать?
Минусы будут?
Самолюбование
100500 раз отвечал
Ты на зарплате и тебе надо создать активность. Либо ты толстый тролль и тогда ты просто больной шиз тут только соболезнования
Я и есть ОП. То есть получается после слов оскорблений ко мне вы всё таки признали, что да, получается надо сделать, как я?
>Ты на зарплате и тебе надо создать активность
а, ясно
Еблан. Делаешь 1 таблицу с квартирами/домами. В ней строчки wifi - тип boolean хотя кто сейчас сдаёт/снимает хаты без интернета?, air_conditioner тип - number или другой числовой, на случай, если в доме несколько кондеев, rooms тип number, всё, зачем тебе 100500 таблиц? Не красиво? А база не для красоты нужна, а для функционирования приложения или ИС
Да но я настаивал на json и postgre, но задача была вроде на mysql поэтому мои аргументы ни что
Да и что ты этим хотел сказать?
Выбираешь дома с комнатами где есть 5г этот один селект
>всё, зачем тебе 100500 таблиц?
Очевидно же, что со временем ты наплодишь на сайте столько свойств, что всё таки решишь делать для многих свойств отдельные таблицы. Это ты сейчас такой весёлый, тебе про 3 свойства рассказали, но их ведь на самом деле за 20, а некоторые вообще могут иметь нестандартные формы.
Нет, я ходил и вижу, что не зря, наблюдая за такими как ты. Хотя тут даже какую-нибудь нищую книжонку по проектированию реляционных баз данных прочитать, хотя бы несколько страниц и уже таких тупых вопросов задавать не будешь
Вообще я против, чтобы читать такие книги. Они место в голове занимают, а его надо отдавать под инфу о том, как создавать продукты, а не как работать на тех, кто создаёт.
Всё что ты делаешь - занимаешься самолюбованием. Наплодил сотню тредов ради внимания. Всем будет похуй на твой аирбнб или сайт по репетиторству. Зачем человеку переходить на твоё говно если есть циан или авито? В чём блять твоё конкретное преимущество? Если бы ты реально хотел разобраться со своей таблицей, то ты бы пошёл читать документацию, а не высирать своё говно.
Так и представляю как захожу на твоё говносайт, страничка которого весить 10 мегабайт и отправляет 100 запросов к бд.
>Всё что ты делаешь - занимаешься самолюбованием. Наплодил сотню тредов ради внимания
И близко не так. Если бы я хотел этого, я бы плодил треды со своими фотками и сотнями скринов своего проекта. Но ничего этого нет.
Какая разница сколько свойств? Ты думаешь, что таблица может содержать ограниченное количество полей или что? В любой момент ты можешь создать ещё одну таблицу и связать их связью, но делать нужно, если это НЕОБХОДИМО. В твоём случае, ты с самого начала городишь какую-то хуйню, с которой в будущем невозможно будет работать
>двач
>Не может решить хранить данные в 1 или нескольких таблицах
>Не может решить хранить данные в 1 или нескольких таблицах
Еблан, зачем ты так жирнишь?
>Какая разница сколько свойств?
вернёмся к этому
А вот ребята которые топят за одну таблицу, а у вас на работе есть такой проект?
Нейронка считает, что лучше несколько таблиц.
Да
Мимо из ozon
Никогда не поверю
>у тебя есть табличка с образованиями репетиторов
что такое образования репитировор?
Ты совсем тупой? Ты понимаешь что такое модель "сущность-связь"? Несколько таблиц, необходимо, когда у тебя несколько сущностей. Например у тебя есть таблица с преподавателями. Есть таблица с образовательными программами. Между ними связь многие ко многим (т.к. одну программу может вести несколько преподавателей и один преподаватель может вести несколько программ), есть таблица с занятиями - это отдельная сущность.
>что такое образования репитировор?
Ну например, один репетитор окончил гарвард и ещё какую-то школу. Это две сущности образования, которые связаны с ним
Никогда не перестану удивляться, как двачеры не могут определиться как хранить такие данные, спрашивают сетку даже, зато выебываются будто все тут неебацца айтишники. И кто-то ведь тут на серьезных щщах что-то спрашивает и не дай бог следует советам. Диванные.
Двачую.
Но вообще, Хранить в одной - это настолько долбоебизм, что даже в голову придти не может.
Это как делать сайт на одном файле
Вообще, от темы треда отошли. А она в том, кто как бы сделал перекрёстный поиск.
Нет, такие уебанские проекты никто не пропустит в продакшн. Есть таблицы с 30 и более полями. Есть базы с 1000 и более таблицами. Такую хуйню пороть простительно, если ты в школе учишься и первый раз на уроке информатики столкнулся с базой данных
Блядь, какие нахуй две сущности? Образование это и есть сущность. Сущность=таблица. Создал таблицу с учебными заведениями, связь - "многие ко многим". Всё!
Окей, понял тебя
Пост на который ты отвечал, он про то, что всё это положить в одну таблицу очень неудобно как бы. Тебе по этой теме есть, что возразить?
Двачую
А вы в курсе что каждый раз запрос будет разным? Сначала человек ищет просто дом, потом с фай фай. И ваш запрос будет меняться.
У тебя моча в голове, иди читай книги по SQL и моделировании структур БД
>Ты про нормализацию данных когда нибудь слышал?
Двачую. СУБД ебанётся столько джоинов потом делать для поиска дома по нужным параметрам.
Если бы я читал книги, я бы ничего не делал.
Так чем плох этот вариант
Вопрос недостаточно тупой. Нужно "Как хранить ноль или единицу, как булен или как тайниинт?"
Создаешь таблицу со связью один ко многим. У тебя будут следующие поля: ID, ID_House, ID_Room.
Потом эту таблицу джойнишь к основной.
Пока большинство выбирают джойн.
Ну чё1?
>кондиционер
В индексы БД записывать модель кондиционера.
Мощность кондиционера позволяет определить количество комнат в квартире 0_0
select houses.houseid from houses inner join wifi on houses.houseid=wifi.houseid
Пока так получается
Пока так получается
Смотрел, как работает эта штука, на сайте w3school
Вопрос к джойникам, это ваше окончательное решение? ОП-хуй сервис делает, т.е. у него одновременно ищут доходяги хибары, вы каждому веб-запросу даете делать что ли джойны всей базы? Вот этот момент поясните плиз
Вообще, у меня сервис репетиторов, но я не хочу привлекать внимание, поэтому для примера про аренду. Но у меня те же проблемы.
В чём я не прав?
Ещё мякотка в том, что эти джоины должны быть динамическими, то есть составляться на ходу.
В том что ты не шавка
Тут скорее вай фай и остальное - общие параметры всего дома. Про комнаты я написал, чтобы дать понять, почему всё не в одной таблице.
Тогда вот.
Если вместо признака вай-фай/кондиционер нужны определённые модели роутеров и кондиционеров, то понятное дело там будет не чекбокс, а строковый тип (если вручную просто писать) или ссылка на таблицу (если есть таблицы с роутерами и кондиционерами)
houses
id
name
ownerid
wifi
id
houseid
wifi (0 или 1)
id
name
ownerid
wifi
id
houseid
wifi (0 или 1)
А зачем тебе таблица с комнатами, вот че ты такого можешь навесить из атрибутов на комнату? Вай-фай и кондер это атрибут хаты в целом, а с фотками в чем проблема по ключу квартиры просто хранить несколько записей со ссылками на файлы? Мое решение позволяет на одну комнату миллион фоток с разных ракурсов хранить, а у тебя только одна будет или придется еще одну таблицу пердануть один ко многим
Да, но со временем ты понаделаешь столько сервисов на сайте, что будет просто неудобно всё про дома держать в одной таблице, и ты начнёшь выносить в отдельные.
Подставил кавычку ОПу за щеку и слил базу его сортиров на рейдфорумс.
ОП-петух, юзай NoSQL, не еби голову.
Капец ты злой. Я то калач тёртый, но тебя же новички послушать могут.
сразу после того как сайт на zerocode делать буду
>пользователь хочет найти все дома, где есть фай фай и одновременно кондиционер.
Делаемъ 4 таблицы:
1 - есть кондей и ви-фи
2 - есть кондей
3 - есть ви-фи
4 - нет ни того ни этого
А как мы привяжем фотки к определённой комнате?
Алсо к комнате можно привязать такие атрибуты как кровать, тумбочка и тд.
Если у каждой комнаты может быть больше одной фотки, то можно сделать вместо ссылки на файл - ссылку на таблицу с группой файлов. И сделать ещё одну таблицу с файлами, которая будет ссылаться на группу файлов.
Вот вариант для нескольких фоток к одному дому, но без привязки фоток к определённой комнате.
При чем тут цикл вообще, мы про SQL моделирование БД говорим.
BLOB
L
O
B
Делаешь в таблице с домами какой-нибудь ПК, хоть адрес, хоть добавь айди дома в виде интегера, хоть хеш из адреса. В каждой таблице добавляешь колонку с ним. Вытягиваешь джойном, как тебе кже сказали, что хочешь.
Для обычного пользователя, которому "удобно" сделай интерфейс с кнопками.
Я честно говоря не понял, в чём вопрос. Я сам не погромист, но давно работаю чем-то вроде лоулевел дата инженегритёнка на саппорте,могу посоветовать подучить SQL и работать с ним именно как с query language, а не какую-то хуйню изобретать. Там куча подводных, зная которые можно охуенно эффективнее запросы делать там, где ебанутые подходы типа тебе все ресурсы выжрут и по времени дохуя займут.
Ни один петух не понимает в архитектуре и индексах.
Прямо как вчерашний тред про одноранговую сеть.
Прямо как вчерашний тред про одноранговую сеть.
>Делаемъ 4 таблицы:
>1 - есть кондей и ви-фи
БРатиш, это можно было бы рассмтреть без смеха, если бы было только 2 параметра - кондей и вайфай. Но их больше 10.
При том, что основной код на php.
Ну ты и долбоеб.
А ты замерял, что джойн тратит меньше времени, чем перебор?
Если кондёр и вифи как чекбокс:
select from house
where 'Наличие вай фая' = true
and 'Наличие кондиционера' = true
and deleted=true
Если кондёр и вифи как ссылка:
select from house
where 'Модель роутера' is not null
and 'Модель кондиционера' is not null
and deleted=true
Приятно быть в компании Дурова
>and deleted=true
false, опечатался
А в джойне можно сразу 3 таблицы делать? А 5?
Шлющка дубацская?
>оракловый
Джойн через запятую везде ж работает?
Насколько это всё удобно динамически составлять?
>это никогда не может стать неудобным
Пocлe дecятoгo лeвoгo oбъeдинeния впoлнe мoжeт c᠋тaть.
Любой каприз за ваши ресурсы
Ты про десять промежуточных связей? Потому что это обычно десять связей с одной сущностью в виде user id.
Фильтрацию всегда делают на стороне SQL сервера потому что там стоят индексы и прочее. Приложение только формирует SQL запросы с нужными фильтрами.
Читайте книги, кабанчика
Быстрее точно будет, чем 100000 раз читать с диска три таблицы, лучше сделать это однажды. Хотя там дохуя подводных. Можно упороться в window functions вообще, но тут я пас.
Вообще рдбмс - это хитроёбанейшая математика и байтодроч.
Так не будет ли в таком случае выгоднее делать всё на циклах и запросах, как я предлагал?
Опытные анальники, поясните в чём я прав/не прав?
Если упрусь, видимо придётся переписывать на джойны.
Ща пути сделаю
Значит когда мы делаем на циклах и запросах, то ход такой
Репетитор который преподаёт математику (1 запрос в таблицу предметов)
который занимается с детьми 9 класса (1 запрос в таблицу классов)
который готовит к ОГЭ (1 запрос в таблицу подпредметов)
который занимается онлайн (1 запрос в таблицу как занимаются)
получается 4 запроса к базам
или мы делаем джойнами, где те же самые таблицы запрашиваются по одному разу
чот у меня получилось что одинаковое количество запросов
Да ты че, база декларативные запросы берет, а под капотом сама шаманит на более низком уровне для эффективного решения задачи. А ты будешь гонять ЦИКЛЫ на скриптовом языке, ну емае ебана
Если ты про время выполнения php, то тут похуй совершенно, потому что такого типа сайты имеют очень низкую нагрузку от пользователей.
Блять, какое же ты ничтожество
Откуда в вас это? Когда я вижу вопросы от начинающих, у меня почему-то нет желания их оскорблять.
Если ты уверен, что соответствующий всем 4 критериям репетитор всегда будет только 1, то ты прав.
И ещё - вместо того, чтобы использовать готовую и оптимизированную логику джойна, ты по сути пишешь её на коленке сам на чём и как умеешь. Я не говорю, что ты неправ, или что работать не будет, это просто изобретение велосипеда.
> сущностью в виде user id
Kaк ты yдoбнo пpидyмaл, кoгдa в᠌ce к oднo឴мy пpивязaнo.
Ну так если нагрузка низкая, то и от джойна ниче не будет, зато если сайт выстрелит и наберет аудиторию, то можно структуру бд оптимизировать, индексов навешать всяких, предрасчеты сделать, а приложение не трогать, а вот так придется копровелосипед мучить ради производительности
Нет, их в выдаче будет 30, скажем. Ага, вот мы и нашли, во сколько раз джойн будет быстрее.
почему ты просто не добавил столбец к таблице домов
Wi fi есть -1 нет 0
и так же для кондишена
нахрена тут отдельная таблица?
Ну у меня на проекте сейчас штук 20 таблиц, и всё норм.
>Ещё мякотка в том, что эти джоины должны быть динамическими, то есть составляться на ходу.
Бред какой-то
JOIN согласно структуры бд
динамические будут параметры в WHERE
Видимо, ты прав. Проблема джойна в том, что для меня он очень сложный.
>штук 20 таблиц
Taк мы нﾠe пpo yчeбныe пpoeкты вpoдe гoвopим, a пp᠍o oбcлyживaниe в энтeнпpaйзe, гдe и пocлe тeбя людям нaдo бyдeт этo гoвнo paзбиpaть.
>из атрибутов на комнату
площадь комнаты, количество окон
имхо не стоит делать такие вещи как наличие вай фай через тру/фалсе
если сделать цифрами - можно будет делать подвиды
0-нет
1-бесплатно
2-за доп плату
итп
Enum имеешь в виду? Можно и так, да
Петух изобрел enum
Потому что таких вещей как кондей штук 20, и у многих много вариантов. Если всё добавить в одну таблицу, получится каша.
А что делать, если из 4 параметров нужен только один?
Делай бочку
Двачую, JSONB в постгре работает ебануто быстро, да еще и индексы можно прикручивать.
Вы начинаете тут опять разводить "а мой язык программирования круче, нет мой". Пока вы гонитесь за идеалом, надо брать и делать.
нахрена ему энум тут?
если потом добавить варианты он заебется еще больше
Пиздец, как не хочется учить джойны.
Битмаск тогда ему надо
Учи агригейты в монге
>Если всё добавить в одну таблицу, получится каша
ОЙ
КОМПИК ТО БЕДНЫЙ ЗАПУТАЕТСЯ В ТАБЛИЦЕ ИЗ 20 СТОЛБЦОВ
Меня мускул всем устраивает в общем-то, только с этой штукой надо разобраться.
Докупишь 500гб памяти и все.
Я пишу код так, чтобы я легко мог читать всё. И таблицы тоже. Это сильно экономит время на работу с кодом.
конкатенируй базовый запрос и нужные фильтры хахаха
Главное бинди 3306 на 0.0.0.0 и отключай фаервол, иначе будет оч плохо работать.
ты ебанулся?
там всей учебы по джоинам на 1 лист а4
Пример кода своими словами можешь накидать?
Я тупой прост. Это мой первый стартап.
Так там можно сразу из 5 таблиц делать?
это не я
clc
sbb eax, eax
xchg esp, eax
push 0
Какой язык программирования? Ты убитый нахуй?
На расте желательно
да у тебя будет строка базового sql запроса с селектом и фромом, а потом ты для нужных параметров делаешь строки для вхере и прицепляешь их к своему базовому запросу
Блядь это же тот самый шиз, который бредит идеей сервиса по аренде домов. Точно он. Блядь, нахуя вы с ним возитесь, если только совсем от нечего делать.
>Я пишу код так, чтобы я легко мог читать всё. И таблицы тоже. Это сильно экономит время на работу с кодом.
давно надо писать "Хуяк-Хуяк и в продакшен"
чистый код с комментами - сейчас это просто халявная помощь гуглу для обучения нейронок
Ну база данных, я про концепцию. Пока одни 3 раза переписывают проект, чёткие пацаны запускают на php и mysql
Это пизда из дева, выше линк был.
LAPS это уровень зашкварных петухов.
а, можно просто подставлять переменную.
LAMP self fix
>А что делать, если из 4 параметров нужен только один?
Динамически формируешь строку параметров для WHERE согласно тому, что пользователь в фильтрах на отбор натыкал. Если он выбрал только один параметр, то и WHERE будет только по нему.
Мне наоборот кажется флексовым, что ты на языке для домохозяек делаешь сложны продукт.
Сложный продукт это когда у тебя 100 микроскрвисов в кубах с кешами, очередями, репликами. А у тебя хуйня ебаная. Такую хуйню мидл на питоне кодит да вечер.
Продукт - это не только код. Это и дизайн, и экспертиза. Её собирать дольше всего.
Какой дизайн если нет базовых знаний про SQL.
Продукт это то что продает отдел продаж.
так все это годами было набором костылей над web 1.0
потом добавили еще больше костылей в виде JS
Из 1999 капчуешь?
Сегодня JS - это лакшери. А костыли - это библиотеки на её основе.
Ты там для тора что-то кодишь что у тебя жс лакшери?
Очередной педофил? Компетентные люди уже в курсе.
>И есть ещё такой момент. Во всех домах разное количество комнат. Максимум - 6.
А если вдруг 7?
Вот реляционные СУБД и были придуманы, чтобы такой хуйней не маятся.
Дома это дома, комнаты это комнаты. Количество комнат в доме, это количество записей в таблице комнат, соотнесенных с записью по дому. Ну для ускорения еще в таблице о домах числовое поле "кол-во комнат" заводят.
О чём я и говорю.
20 лет назад
у каждой домохозяйки был свой сайт
а сейчас долбоеб не может сделать сервис по аренде домов с парой джоинов на эскуэль
В ПЛАНЕ ВЕБА МЫ ДЕГРАДИРОВАЛИ
Ты это, думай, что говоришь.
Раньше сайт у домохозяйки был в лучшем случае с гостевой книгой, где была одна таблица и всё выводилось по дате desc.
А сервис по аренде домов - это блядь просто монстр с десятками таблиц и сложными запросами на выдачу.
Так это как раз один и тот же атрибут - кондей, вайфай, мусоропровод, тип отопления и тд. Ты на каждый такой по таблице собрался создавать?
Тут даже по архитектуре это рядом не стоит. Ты попробуй придумай, как всё это хранить так, чтобы ты мог этим пользоваться.
>Ты на каждый такой по таблице собрался создавать?
Естественно. И это правильно.
И как это будет выглядеть? Звучит очень странно.
Выглядит очень естественно. На каждую сущность по табличке.
Просто скачай какой нибудь движок из интернета сайта на php и mysql, там будет то же самое.
луркай якорную модель и дата волт по этой теме
Как будешь выбирать все типы удобств для одного дома? Приведи пример запроса.
Пук среньк джоин
У тебя тут одна и та же сущность - удобства. Описание, название, тип и тд это уже данные сущности.
у нас есть главный цикл, который просто берёт подряд все айдишники домов
мы взяли айдишник и смотрим, задал ли пользователь чтобы был вай фай. если задал, то делаем запрос в базу и смотрим есть ли он
если нет, дропаем этот цикл, увеличиваем переменную с на один, и берём следующий айдишник
если есть, идём дальше
и так с каждым параметром
Пример приведи. Пока что твоя идея выглядит и звучит как говно.
Скажем так, не подряд, а уже отсортированные алгоритмом.
ну как как ёмаё
селект * фром хаус Х
джоин кондиционер К
он К.хаус_айди=Х.айди
джоин вай фай ВФ
он ВФ.хаус_айди=Х.айди
джоин джакузи Д
он Д.хаус_айди=Х.айди
Таким образом выйдут все дома в которых есть кондиционер, вай-фай и джакузи
Согласны? Узнали?
это с джойнами
select id, ... from houses
where exists (select id from wifi where wifi.house_id = houses.id)
and exists (select id from conditioners where conditioners.house_id = houses.id)
>он К.хаус_айди=Х.айди
блядь вот эта хуйня просто выбешивает нахуй
>запросы в цикле
Если сервак не дорогой, то пара десятков человек человек его положат этими запросами.
Джойны медленные на больших данных вот решение если надо просто проверить существование
Ага, ещё такой вариант есть
А кто-нибудь может объяснить почему такой вариант не подходит? Просто берём и фильтруем по where нужные удобства.
Безопасно, они сами своих кур едят. Там же можно взять яйца из под курочки, гусей-кролей-индюков-перепелок, свинину с говядиной и прочие редкие в шестёрочках вещи. Ищи на авито или на рынке, на рынке всегда дороже, там не частники а перепуки сидят
Причем запросы могут быть ОЧЕНЬ специфичными. Я там и натуральный воск беру, и сборы трав редкие-разные, и телячью печень и яйца из под черной курицы нашла это в ведьмотред скорее у ничего не подозревающих обывал
Не придираюсь, просто стала больше прислушиваться к своим желаниям, если не лезет кусок и нет аппетита, значит что-то не так с едой.
В итоге, да много идет на выброс. Что-то очень быстро портится, хотя на след. день, если говорить о готовой еде, или после одной разморозки, если говорить о замороженном фарше, например, не должно так быть.
Это несвежая. А если срок годности и запах норм просто помой ее водой и оботри бумажным полотенцем.
Я когда была в отпуске покупала в дорогом супермаркете (дома такого нет) нежнейшее свежее мясо, да было очень вкусно, но и четверочка норм если в специях/маринаде готовить.
Могу я экзистом проверить наличие строки где houseid = 1 и wifi = 1?
Да, я понимаю, что это потенциальная проблема.
селект * фром хаус Х
вере айди ин (селект хаус айди фром кондиционер)
энд айди ин (селект хаус айди фром вай фай)
эед айди ин (селект хаус айди фром джакузи)
Уточни вопрос. Существование строки в таблице с домами, где id = 1 и чтобы у этой строки была связанная строка в таблице вайфаев, где тоже id = 1?
select 1 from houses
where houses.id = 1
and exists (select wifi.id from wifi where wifi.house_id = 1 and wifi.id = 1)
Если получил 1, то есть, если получил пустое множество, то нет
Кто селедку ел? Вкусно?
Ну вот, умные двачеры ближе к ночи подтягиваются
А зачем тебе джойнить возможные десятки таблиц если можно просто запросить все удобства одного дома по его айдишнику? Так и сам запрос короче станет, и сущности плодить не придется.
>>Ты на каждый такой по таблице собрался создавать?
>Естественно. И это правильно
Появилось новое удобство добавляем таблицу?
Добавлять таблички в процессе боевой работы это такое себе.
Нет удобства мы загоняем в таблицу-справочник Удобства, где будет id_удобство и название.
а сами признаки для дома будем хранить в связующей таблице id_дом, id_удобство
Добавление удобства "бесплатный минет от хозяйки" в базу это будет простое добавление записи в таблицу удобств
Жиза, курицу как не возьму вся какая то вонючая, в соплях и слизи. Слава богу, что рядом с домом есть один гипермаркет где можно найти годноту, а так 80% того что в магазинах это невкусный кал. Что ж поделать, сейчас стараются максимально удешевить производство всего, а на людей плевать, кабанчиков интересует только прибыль
Да, но для этого придётся всё хранить в одной таблице, а не всегда это возможно, просто потому, что некоторые параметры могут быть переменными, для одних домов одни, для других другие. И хранить в таблице сотни столбцов подо всё это - просто идиотизм.
>Появилось новое удобство добавляем таблицу?
Да, но это происходит редко и терпимо.
Ой ребят, а как же отзывы? Отзывы тоже добавлять в таблицу к фай фай?
Для отзывов нужна новая база данных.
Разные параметры можешь хранить как json в отдельной колонке. Они все равно привязаны к конкретному дому и конкретному типу удобства.
Всё от задачи.
Если удобства все заранее известны или добавляются очень редко при правках ТЗ, то надо делать обычные таблицы, потому что у разных удобств разные атрибуты, например у WIFI есть ESSID, у минета от хозяйки есть цена за час, разные поля с разными типами данных.
Если дополнительных атрибутов никаких нет, то можно создать одну таблицу как ты сказал.
Если удобства часто добавляются или вообще динамически и у каждого свои атрибуты, то можно создать JSON столбец, но в таком случае лучше вообще смотреть в сторону документоориентированных баз данных, реляционные при частой смене схемы плохо подходят.
я не знаю что такой джесон
Дело в том, что ещё по этим параметрам ведь поиск вести надо, поэтому хуярить через запятую не подойдёт.
BSON
ProtoBuf
Столько усилий ради чего, чтобы вместо нормальных множества таблиц делать одну?
Значит ты хуйни понаделаешь сторудово. Советуй тебе - не советуй. Без разницы, ведь нормально сделать ты не сможешь.
Это ДМЗАЙН, ВЫ НИПАНИМАЕТЕ ЭТО ИСКУСТВО
Я же написал, что множество таблиц тоже возможно, чаще всего лучшее решение, классика. Но иногда задача требует другого подхода.
Понаделсю, ключевое слово.
В поиск по jsonам умеет постргресс или монгодб.
Смеха ради, в самом начале, когда я занимался проектированием сервиса, у меня ведь первой появилась идея хранить данные в одной строке. Но через какое-то время я понял, что работать с этим будет просто невозможно.
>я понял, что работать с этим будет просто невозможно
>И хранить в таблице сотни столбцов подо всё это - просто идиотизм.
А что такого в том чтобы хранить много полей в одной таблице?
стэтхем же
>А что такого в том чтобы хранить много полей в одной таблице?
Я уже писал, что некоторых полей может быть больше сотни.
И что с того?
Плюс, разнеся данные по 20 таблицам, меняя адрес дома, мы не будем дёргать все данные сразу.
>Всё от задачи
А ОП не может поставить задачу.
Чтоб поставить задачу надо понимать что хочет клиент, при этом вникнув в его бизнес-процесс, и как и какими инструментами это будет решаться девелоперами.
А ОП в основах путается.
Я не знаю, насколько нормально это сможет работать. Я точно не смогу работать с такой таблицей, а это важный фактор.
Если ты про ОП пост, то там намеренно примитивный пример, чтобы просто не усложнять. Да это и не нужно.
Собственно задача в том, что есть три таблицы, в одной типа просто дома, в другой фай фай, в третьей кондеи, и нужно найти дома, в которых есть и то и другое.
Тебе уже дали ответ и с джойнами и с экзистами. С экзистами эффективнее. Если тебе НЕ надо инфу из таблиц вайфаев и кондеев, а только дома, где есть и то и другое, то выбирай экзисты.
Очень хороший ответ.
Я правильно понимаю, что выигрыш в том, что уменьшается количество запросов к mysql серверу?
надо нанять програмиста SQL, он в базе сделает тебе требуемую отфильтрованную динамическую таблицу (встроенный запрос-представление) ,
ты ее откроешь в своем питоне и обработаешь.
С экзистами есть подзапрос, но операция джойна сама по себе очень дорогая, дороже экзиста, и она будет тем дольше, чем больше у тебя данных и больше таблиц, которые джойнишь, время выполнения будет расти очень быстро.
Не тащи это сишное говно в базы данных.
Можно потом ради интереса будет потестить. Нагенерить тысячу профилей и гонять сервак запросами.
Спасибо за комплимент. Я на си ещё не писал...
Общепринятый далбаебами паттерн. Потом у тебя навалится миллионов 10 записей и ты ебанешься собирать свои объекты из атрибутов, будет все тормозить. Позовешь такого же придурка, он предложит докупить серверов и размазать по данные по ним. Потом еще балансер прикрутить.
Будет 2000 таблиц, тогда и приходи.
миллионов 10?
Давайте посчитаем для США.
Допустим, у нас 100 000 домов. У каждого по 20 атрибутов. 2 миллиона. Но.
пользователей то у нас миллионы. каждый год. И у некоторых по несколько покупок. Это тоже всё в одну таблицу?
Это просто тупо.
>Это тоже всё в одну таблицу?
Конечно, ведь это же паттерн. Чтоб все охуели.
Неосиляторы SQL и реляционной модели такие смешные.
Долбоеб не понимает что такое таблица.
Таблица список домов, там инфа, которая уникальна для дома и может быть только в одном экземпляре. Номер дома, адрес, статус занят/не занят, хз, чё там ещё.
Таблица кондиционеры, там перечисление вообще всех кондеев с их уникальными характеристиками (этаж, фирма, статус, хз). Для каждого указан внешний ключ — айдишник дома, в котором кондей находится. Схожие таблицы и для всего остального — тех же вайфаев, например.
Тут подразумевается, что фотографии ты хранишь тупо в питоновском списке, а сама информация о квартире - это питоновский же словарь, типа:
{
"rooms_number":2,
"wifi":false,
"rooms":[
"link_to_pic1.jpg",
"link_to_pic2.jpg"
]
}
и тогда поиск работает через какое-нибудь REST API приложение.
А вы на работе какие проекты делаете?
И вот такие "специалисты" хотят среднюю зп по рынку, а то и даже выше.
>Собственно задача в том, что есть три таблицы, в одной типа просто дома, в другой фай фай, в третьей кондеи, и нужно найти дома, в которых есть и то и другое
SELECT House.id FROM House House
WHERE House.id in (SELECT Wifi.house_id FROM Wifi Wifi )
AND House.id in (SELECT Ac.house_id FROM Ac Ac)
второй это я, и я ни в коем случае не хочу среднюю зп по рынку
Господи пиздец какой зоопарк слов
Фу, что за непотребство.
Лучше бы подумали о том, что юзеры сайта будут за 1 раз смотреть 20 квартир в выдаче, а дальше будет подгружаться страничка, или кнопки 1, 2 ... 99 с номерами страниц (но сейчас так обычно не делают).
Я писал об этом в треде
Аноны анальники обьясните мне лучше другую хуйню
Почему в TLS первые запросы клиент-хелло передаются не шифрованными? Там же хранятся рандомные номера якобы для невзламываемости запросов. Что мешает моему провайдеру сделать митм и подсовывать свои запросы вместо запроса клиента, и по крайней мере читать то что приходит от сервера? Почему не завернуть первые запросы в публичный ключ СА сервиса уникальные для сайтов зареганных у этого СА?
Потому что в первом запросе передается какой именно сайт тебе нужен
На 1 IP может висеть несколько разных виртуальных серваков, с разными доменами и сертификатами от разных CA.
Тебе надо как то сообщить какой именно сайт ты хочешь, что бы он стал тебе отвечать нужным сертификатом.
Вообще это вроде как то решили уже, когда TLS HELLO тоже шифруется. Но тут я хз как от MITM защищаются.
С самим сайтом все понятно - сертификат не будет соответствовать домену. Ну если ты конечно не долбоём с установленными сертификатами минцифры
Придурки, нахуй вы его чему-то учите бесплатно? Вам делать нехуй? Вы можете себе блять представить чтобы юрист или маркетолог или арбитражные кому-то так бесплатные советы раздавал?
О, шиз, который все никак не допишет сервис с репетиторами, ты? Узнал тебя по твоему «сервис по аренде домов»
Как там успехи? Чего вдруг перестал высирать треды «что мешает тебе создать свой айрбнб»? Смотрю тебе резко стало мешать отсутствие навыков программирования?
Но зато как резво ты тут пиздел, что изи освоишь и дизайн, и программирование, и маркетинг)
Делиться знаниями очень приятно.
Потому распространение знания, тем более базы, это хорошо.
ОМГ, думаешь ето он?
а клиент при каждой установке соединения обращается к СА, или только при первом соединении? или только когда есть сомнения в подлинности сертификатов?
Ты подожди, он еще не нюхал High-Load, High-Availability
И всё что с этим будет связано.
Типа реплик, хранения сессий в Редисе, K8S кластер с blue/green деплоем новых версий и тп
Но сдаётся мне, он до этого этапа дойдёт примерно никогда
Клиент вообще обычно не обращается к CA
На клиенте обычно есть доверенные CA сертификаты, от которых можно построить вниз цепочку доверия до конкретног сертификата сервера.
Клиент может обращаться к списку отозванных сертификатов.
Обычно для каждого CA есть URL с этим списком. который клиент знает, так как у него есть сертификат самого CA в доверенных
OCSP называется
> Чего вдруг перестал высирать треды
Сегодня был тред точно
100%
Та же манера письма
Те же витиеватые заходы через «сервис по аренде домов»
вот тут высрался таблицей с образованием
Ну и тренды про айрбнб говорят были сегодня опять
Да какой high availability, об этом начинает заходить речь когда есть трафик и есть клиенты. Шиз не осилит привлечь даже трех инвалидов.
Для начала я бы не ебал себе мозг и сделал обычный питоновый блок в n8n. Нахуя ты такой ретроград?
Я бы тебе ответил, но первая и особенно третья пикчи это желание истончают. Кончай засирать этим безвкусным говном мой /би/, пидорас.
Слышал что-нибудь про JOIN и EXISTS?
Пайтон не лучшее решение для веб.
Не отвлекай АРХИТЕКТОРА, чернь
А mysql - это просто хуита.
При этом пайтоном владеет каждая макака, например.
Таблица с домами, таблица с атрибутами домов, например, адресами, внешние ключи на них, таблица с кондерами, таблица с wi-fi, общая таблица - связка домов с кондерами. Пиздец же как это сложно. Должны на любых курсах по БД рассказывать, но там, походу, такие же ебанавты, как ОП.
Мускуль одна из самых лучших БД эвер. Стабильная, быстрая, с возможностями. Пруф ми вронг, жопорукич.
Есть организационный минус: ребята злоупотребляют FUD-ом в отношении GPL, чтобы перевести лохов на свою проприетарную лицензию. И подставляют тем самым всю опенсорсную движуху. Как цыгане, блядь. Тот же постгрес в данном отношении ведёт себя намного приличнее.
Допустим, я решил создать сервис по аренде домов.
У меня есть таблица с домами и есть таблицы, в которых хранятся другие параметры - вай фай, кондиционер. Параметров очень много.
И есть ещё такой момент. Во всех домах разное количество комнат. Максимум - 6. Для каждой комнаты есть своя фотография, и получается, что если все данные хранить в одной таблице, то в каждой строке будет по 6 столбцов на комнаты, и в большинстве строк там будет пустота, ведь там ничего нет. Не красиво.
Поэтому для каждого типа данных отдельные таблицы.
Теперь вопрос - как бы вы реализовали поиск одновременно по трём таблицам?