Bymas | Как правильно?

Не знаю как такое загуглить, поэтому пишу здесь. Допустим у меня название таблицы находится в переменной. Есть обертка для подготовленных запросов. Как правильно прописать?

php

# Так?

db::fetchAssoc("SELECT * FROM `$table`");

# Или

db::fetchAssoc("SELECT * FROM `?`", $table);

# Или даже так?

db::fetchAssoc("SELECT * FROM ?", $table);

# 4 вариант

db::fetchAssoc("SELECT * FROM $table");

________
посл. ред. 02.09.2023 в 13:09; всего 1 раз(а); by Something

Something , Первый вариант

Никогда не встречал, чтобы таблицу указывали через подготовленные запросы.
Даже если такое возможно и в переменной table нету данных из вне, то правильным будет 1 вариант

В целом первый вариант без `
Почему без них, только mysql саппортит их в остальных случаях при потребности сменить бд они не нужны и будет лишний рефакторинг

Но в данном случае вообще лучше реализовать один из паттернов DAO AR или DM так как есть подозрение что данные дальше ходят через прямые query, хотя если в системе есть сервисы и репозитории то ещё пойдёт
________
посл. ред. 02.09.2023 в 13:05; всего 1 раз(а); by Scammer

Scammer (2 сен 2023, в 13:02)
В целом первый вариант без `
Почему без них, только mysql саппортит их в остальных случаях при потребности сменить бд они не нужны и будет лишний рефакторинг

Зачем они нужны вообще?

Something (2 сен 2023, в 13:04)
Зачем они нужны вообще?

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

Scammer (2 сен 2023, в 13:03)
Но в данном случае вообще лучше реализовать один из паттернов DAO AR или DM так как есть подозрение что данные дальше ходят через прямые query, хотя если в системе есть сервисы и репозитории то ещё пойдёт

ORM? А смысл? Кода больше, нагрузки больше, читаемость хуже.

Something (2 сен 2023, в 13:07)
ORM? А смысл? Кода больше, нагрузки больше, читаемость хуже.

На самом деле нагрузки не значительно больше если нет моментов где выборка идёт сотен записей и в обернутом виде, читаемость от этого стает лучше и масштабирование возможно, а когда оно размазано по всему проекту то достаточно сложно вносить изменения в будущем.
Например если вдруг какой-то из модулей свитчается к примеру на clickhouse (Так как работает с большими данными и надо менять технологию запросов, допустим модуль typeahead)
Так вот когда есть репозитории и сервисы и правильно используются DTO то это сделать достаточно легко изменив лишь репозиторий откуда подгружать данные даже больше можно делать a/b тестирование такой фичи, а когда оно все работает в mvp стайл то придётся кучу всего переписывать и костылить для внедрение нового

И в целом кейсов таких достаточно большое количество но это больше к проектам enterprises или Ecommerce применимо ну и в других больших вертикалей, если речь про трафик пару тысяч людей в месяц и стабильный онлайн до сотни то можно как угодно строить архитектуру лишь бы не упороться в большие данные после чего придётся переписывать все