вводим страну(в базе есть англия, германия, франция, испания, италия) и результатом будут города, всё это дело работает через ajaxниче не ясно, дохрена кода, нихрена не понятно. Возвращаете вы что? Список городов принадлежащих стране? Листаете постранично как? Через линки или тоже аяксом?
Если же данные клиента не полные, то данные сохранять только в заданиях (таблице 2).Почему? Чем обусловлена такая хитропопая логика? Вам от клиента по сути нужен уникальный номер, дальше привязывать к нему какие-то данные или нет вообще вопрос вторичный. Данные во вторй таблице(`customer_name`, `customer_phone`, `customer_email`) вообще не нужны, это нарушает 3 нормальную форму.
objectid in( ... )
и по результатам раскидывает их в объект $images(это коллекция картинок) каждому объекту из коллекции итемов (или юзеров или чего другого). В итоге каждый объект имеет в составе коллекцию изображений. $sql = "INSERT INTO tasks (`task`, `date`, `time`, `users_id`) VALUES ('$task', '$date', '$time', $users_id)";
var_dump($sql);
R::exec($sql);
есть две таблицы "countrys"в смысле countries? И это, запятые экономить не надо, навряд ли у вас 2 таблицы countries.
и вторая таблица "citys"в смысле cities?
и countri_id, последний это id страныв смысле country_id?
список нужных городов а как теперь сделать не весь список, а скажем только по 5 городов на страницу не понимаю.ЗАПЯТЫЕ!!!
по 5 городов на страницуво первых - не вижу ни кода, ни запроса которым вы пытались это сделать.
Сделал другую ссылку с полным списком городов и в нем постраничный вывод всё норм, а как теперь в него засунуть еще и выбор страны не понимаюну так а какая разница, тот же селект, просто добавляется условие where country_id = и номер страны.
У каждой заявки множество специфичных конкретно для нее параметров.значит вся "специфика" должна быть вынесена в отдельную таблицу. А херачить на каждый чих колонку - решение такое себе, по многим соображениям.
1. Индексы, выборочно для полей, по которым чаще всего осуществляется поиск.скорее для групп полей, по которым осуществляется поиск, выборка, объединение и сортировка. Кроме того - explain, slow log.
2. Объединение нескольких колонок в одну, для однотипных данных. Они будут храниться в формате JSON.только если по ним не идет поиск, иначе это нифига не оптимизация, а скорее наоборот.
SELECT * FROM `posts`
WHERE 1
ORDER BY `rating` DESC
LIMIT 40,10
Все по порядку как положено (AUTO INCREMENT)и тут посты с ид 5 и 12 удаляются, и - опа, не по порядку (
ALTER TABLE `tablename` ADD `unique_id` VARCHAR(24) NULL , ADD INDEX (`unique_id`);
$id = $_GET['edit'];
здесь $id в итоге может быть вообще пустой, или с шикарным sql инжектом.$get = mysqli_query($db, "SELECT * FROM users WHERE id = '$id'");
можно только надеяться что выше есть объявление $db$str = mysqli_fetch_array($get);
неплохо бы проверить что запрос что-то вернул вообщеif(isset($_GET['edit']))
если это условие не выполняется, переменная $str вообще нигде не будет создана.Я понимаю что эта переменная видна только в if. Как ее вывести?
<?php echo @$dif; ?>
- совсем кривой подход), такой подход оправдан только в ограниченном ряде случаев, например если много переменных могут быть не определены и код нужно рефакторить, но некогда. что заставляет перебирать все 1000 записей, а WHERE id > 1000 LIMIT 10, что не заставляет перебирать все 1000 записейУ вас нет никакого понятия как работают индексы, по этому вы думаете что так будет быстрее. Хотя логика подсказывает что за 20+ лет существования реляционных бд наверняка при необходимости повысить производительность до такой опции бы давно додумались и она была бы распространена, но почему то такого не случилось... Это по тому что достаточно
Как из этой таблицы выбрать историю диалога когда известен id отправителя, например 1
SELECT m.`id`, m.`message`, mr.`message_id` status
FROM `messages` m
LEFT JOIN (
select `message_id`
from `messages_read`
where `user_id` = 111
) mr
ON mr.`message_id` = m.`id`
WHERE m.`chat_id` = 12