Задать вопрос
  • Кто поможет переписать SQL запрос?

    shaks
    @shaks
    Я не совсем понял что у вас где храниться, и зачем вам логин аккаунта, но подразумеваю что вы имели ввиду что баланс юзера хранится не в таблице users а в таблице lm_balance

    Эти таблицы объединяет только одно ИД аккаунта

    Во первых имя колонки с id аккаунта (ид юзера в вашем случае) должен называться user_id а не name (судя по вашему sql запросу).
    Во вторых, balance = balance +" . floor($_credits) . " - за это руки вырывать надо, с корнями.
    Баланс ведите в наименьшей величине, если баланс рублевый - в копейках, долларовый - в центах, биткоиновый - в сатоши, и тд, и ничего не округлять никогда, если хотите чтобы сводился дебит с кредитом. При работе с большими числами лучше использовать либу по работе с большими числами
    В третьих, ид юзера нужно просить не юзера ввести, а брать из сессии (если у вас сессионная авторизация).
    В четвертых, функции mysql_* уже давно устарели и помечены как деприкейтед. В пхп7, если я не ошибаюсь - драйвер mysql убрали.
    Ответ написан
    Комментировать
  • Какие есть идеи для выполнения очень большого запроса?

    @res2001
    Developer, ex-admin
    1.Сделать необходимые индексы.
    2.Разбить большой запрос на несколько маленьких. Даже если по коду будет казаться больше, но обычно несколько маленьких запросов выполняются быстрее, чем один большой. Запросы объединяйте с помощью временных таблиц или union.

    PS: Вообще то что вы описали, не есть что-то страшное. Подобные запросы встречаются сплошь и рядом в разнообразных корпоративных системах. Начните с индексов, возможно до второго пункта и не доберетесь.
    Ответ написан
    Комментировать
  • Как сортировать в sql?

    @d-stream
    Готовые решения - не подаю, но...
    Работает. Только моя телепатия подсказывает, что balans - строковый а пытаются хранить в нем цифры и потом возникает удивление почему 100,01 располагается не так рядом со 100,11
    Ответ написан
    5 комментариев
  • Как лучше организовать структуру данных в БД?

    @totosarg
    Проверял? Проверял. Работает? Работает. Не трогай!
    Вы лучше простыми словами опишите, что хранить надо? Я так понял, у вас есть пациент, и его данные, и есть анализы? Типа Эритроциты, РОЕ, и все такое? вопрос в чем? как хранить анализы для пациентов? A анализы у вас как выглядят? 1 запись со всеми анализами, или для каждого анализа своя запись? (данные вы как получаете, или их кто-то вводить будет)? Как собираются пользоваться этими данными? По каким полям требуется поиск? Ответ на ваш вопрос зависит от ответов на мои вопросы :). И вот, советую ознакомиться: https://en.wikipedia.org/wiki/Database_normalization
    Ответ написан
    Комментировать
  • Задачи и упражнения для SQL?

    gromdron
    @gromdron
    Работаю с Bitrix24
    А чем sql-ex.ru не устраивает? Очень добротный и хороший ресурс.

    А вообще - Практика по SQL - вопрос уже задавался :)
    Ответ написан
    1 комментарий
  • Как сформировать правильный sql запрос?

    DevMan
    @DevMan
    примерно так:
    SELECT
        *
    FROM
        `dle_post`
    JOIN
        `dle_post_extras` ON `dle_post_extras`.id = `dle_post`.id
    Ответ написан
    2 комментария
  • Стоит ли разнести данные в БД: на пользователя своя схема?

    @Sumor
    Работает - не трогай.
    А по сути, вопрос в том, что вас не устраивает в текущем хранении и насколько связаны данные разных пользователей.
    Если данные пользователей тесно переплетены, то есть Products, Items связаны с несколькими пользователями одновременно, но может нет смысла так заморачиваться.
    Если же данные пользователей наоборот разделены, то вы можете рассмотреть вопрос о создании под каждого пользователя своей БД. При заведении пользователя она будет создаваться, при удалении - удаляться, сохранение/восстановление/права - всё будет.
    Если хотите поиграться схемами, то лучше использовать не таблицы, а представления. На каждого пользователя создать представления в своей схеме с отбором только его записей и выставлением прав.
    Ответ написан
    Комментировать
  • Как выдать верный результат SQL?

    Winsik
    @Winsik
    сис.админ, недопрограммист :)
    SELECT id FROM  T  where o =1 and id in (select id from t where o=2)

    вариант два:
    select id from (
      select id, max(o1) as o1, max(o2) as o2 from (
          select id,1 as o1, 0 as o2 from T where o = 1
        union
          select id,0 as o1, 1 as o2 from T where o = 2
      ) as T1 group by id
    ) as T2
    where o1=1 and o2=1
    Ответ написан
    5 комментариев
  • Как сделать рекурсию в запросе?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    В запросе такого не сделать, но и рекурсивность тут не нужна, достаточно простого цикла. Можно написать хранимую функцию или процедуру, но если такой запрос нужно выполнять часто, то лучше сменить модель хранения и использовать Nested Set.
    CREATE FUNCTION SearchRoot(id INT)
    BEGIN
      DECLARE parent INT;
      SET parent = id;
      REPEAT
        SET id = parent;
        SET parent = (SEARCH `id_parent` FROM `table` WHERE `id` = id);
      UNTIL parent > 0 END REPEAT;
      RETURN id;
    END
    Ответ написан
    Комментировать
  • Как поменять местами column в MS SQL?

    Qairat
    @Qairat Автор вопроса
    frontend developer, angular 2+
    Чтобы поменять местами столбики для начало надо зайти сюда sql server -->Tools-->Option--> designer-->Table and database Designers и убрать галочку
    0deea3e3b3a348a699351c4f4ec99673.PNG
    а потом уже можно менять местами все что хочешь!
    Ответ написан
    Комментировать
  • Какие ресурсы необходимы для увеличения скорости работы с большой таблицей sql?

    При миллионе записей 1 секунда на подсчёт количества??

    Да у вас вообще индексы есть на эту таблицу и колонку id?

    О каких аппаратных ресурсах может идти речь, научитесь СУБД пользоваться.
    Ответ написан
    4 комментария
  • AZURE MS SQL очень медленно работает! Что сделать?

    impwx
    @impwx
    Разработчик
    Может быть, проблема в самом SELECT? Что показывает план запроса?
    Ответ написан
    2 комментария
  • Как спроектировать БД для диалогов?

    @bnytiki
    Есть ли более "красивые" методы связи диалога и пользователя?
    Вариант завести еще одну таблицу dilog_users
    dialog_id | user_id
    1 | 2
    1 | 3
    1 | 4
    1 | 5

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


    MySQL - это РЕЛЯЦИОННАЯ СУБД.
    Для нее абсолютно нормально и совершенно естественно хранить данные именно так.
    Про раздувание СУБД не стоит волноваться - современные СУБД спокойно хранят миллиарды строк и быстро с ними работают.
    Метод же с LIKE - абсолютно неестественен для реляционных СУБД, что по мере "раздувания" СУБД приведет к крайне медленной работе.
    Ответ написан
    Комментировать
  • Sql взять подстроку используя Regexp?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    stackoverflow.com/questions/33874402/sqlite-regula...
    можно написать запрос вида
    select (select ... ) as a, (select ... ) as b, ...
    но imho проще порезать на любом ЯП
    Ответ написан
    Комментировать
  • Sql как сравнить строки?

    romy4
    @romy4
    Exception handler
    Вам как минимум тут нужно привести пример таблиц людей и кредитов, и их связей. Тогда продолжим
    Ответ написан
    2 комментария
  • Как сформировать sql-запрос для поиска в нескольких таблицах одновременно?

    @DuD
    А еще можно соединить их в одну вьюху и селектить из одной как из обычно таблицы.
    Ответ написан
    1 комментарий
  • Запрет на join? Оптимизированная выборка из связи многие-ко-многим без join с параметрами из линкованных таблиц?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    Они так говорят, потому что:
    1) Если вы везде используете JOIN то на большом проекте у вас перестаёт работать кеш встроенный в БД, т.к. insert или update хотя бы в одну из таблиц участниц join сбросит кеш всего запроса, а на больших проектах изменения данных идут постоянным потоком.
    2) JOIN делает жётские связи на уровне данных, это хоронит возможность оптимизации на уровне архитектуры приложения. Когда таблицы не связанны внешними ключами и запросами то мы можем перенести любую таблицу, в другую БД оптимизированную для нужных типов запросов, написать например на Си отдельный сервис/демон для этих данных. При этом нам надо будет переписать только одну сущность в приложении. В случае с разрешёнными JOIN может выясниться что переписать надо вообще всё.
    3) Существует популярный подход переваривания больших нагрузок/данных это шардинг, т.е. раскидывание диапазонов данных по разным серверам, это когда первые 10 миллионов записей лежат на одном сервере а вторые на другом, join в этом случае сделать нельзя.
    4) Нормализация, полностью нормализованная БД самая медленна(т.к. куча JOIN, каждый из них это умножение двух матриц), но зато самая компактная, полностью не нормализованная БД самая быстрая (так как всё берём одним простым запросом), но очень жирная и неприемлемо сложная в работе.

    Ваш пример очень абстрактен, если про него ясно только, что данных очень много и не известно кто и в каких условиях будет с этим работать, но скорость ответа важна, а количество запросов будет большими. (Например это API к которому сторонние люди будут писать приложения и потенциально рекламировать эти приложения по ТВ)
    То например так:
    1) Запросом c JOIN скормить данные этих двух таблиц в поисковый индекс на sphinxsearch
    2) Делаем запрос с параметрами book.param = 1 AND author.param = 2 поисковому индексу сфинкса, он возвращает нам PK ID нужных сущностей
    3) Делаем SELECT * FROM t WHERE id in(1,2,3..N)

    Таким образом мы получаем сложную и тяжёлую фоновую индексацию, но очень быстрые и отъедающие крохи ресурсов сервера запросы в онлайне. Из минусов сильно усложняем архитектуру, а соответственно написание, отладка и поддержка кода становятся намного дольше, а количество людей которые могут это делать намного меньше, что в свою очередь является серьёзной проблемой но другого уровня.
    Ответ написан
    Комментировать
  • Запрет на join? Оптимизированная выборка из связи многие-ко-многим без join с параметрами из линкованных таблиц?

    @doktr
    Data Scientist
    Если поля, по которым производится JOIN, имеют индексы, то запрос будет идти гораздо быстрее, чем без них, так что нужно смотреть индивидуально. Если индексов нет, то в плане выполнения, скорее всего, будет FULL SCAN и итоговое время будет пропорционально произведению количества строк в двух соединяемых таблицах - O(M*N).
    Ответ написан
    Комментировать
  • Что в себя должна включать поддержка ПО и сколько за это брать денег?

    @Joysi75
    Не зная софта тяжело сказать что и как требуется. Но обычно:
    1. Гарантийные обязательства обычно включают в себя:
    - Указание срока его предоставления.
    - Исправление критических ошибок
    - Консультирование клиента в рамках функционирования ПО (отдельно можно описать круг тем).
    - Обновлении версий
    - Функционирование ПО в рамках обязательств заключенных в договоре (или приложении ТЗ к нему) или указанных в акте (или иных договоренностей) на момент сдачи ПО.
    - Иное обслуживание ранее указанное в договоре/акте/... на момент сдачи ПО. Например, Вы договорились что у клиента ориентировочно через 3 мес откроется пару филиалов и Вы настроете ПО на работу с ним.

    2. Поддержка может включать в себя обычно: техническое обслуживание, аварийное обслуживание, обучение.

    2.1 Аварийное обслуживание. Заранее прописывают 2 вещи: категорию аварии и время реагирования/время устранения + штрафы(не обязательно финансовые, может быть разрыв договора) в случаи нарушения. Например,
    1я категория - не запускается софт (например из-за установки service pack на ОС) время реагирования=30 минут, время устранения=3 часа.
    3я категория - криво сформировался ежегодный отчет (в следствие нарушения данных и т.п.) . Время реагирования=1 час, время устранения=5 раб. дней.

    2.2 Техническое обслуживание. Обычно тут "хотелки" (написать небольшой дополнительный функционал, например, добавить ИТОГО,графики + доп колонки в какой-либо отчет) либо доп. требования (например, выгрузка каких-либо данных для налоговой из инет-магазина при изменении законодательства). В договоре опять-же категоризируют такие работы (например: установка дополнительного АРМ, экспорт-импорт данных в XML/JSON/TXT в стороннее ПО ...) и устанавливают доп цены на них принципу:
    N штук таких работ выставляют в виде периодической абонплаты, а выше N - по отдельной цене (например, за фиксированную почасовую оплату). Будет хорошо, если вы приложите расценки с указаниям кол-ва часов для решения наиболее возникающих проблем. Также указывают штрафы при нарушении сроков и т.п.

    2.3. Обучение. Обычно после сдачи софта разработчик берется:
    - Обучить N сотрудников работе с ним в течении X дней.
    - При изменении версии (или критическом обновлении) произвести обучении M сотрудникам в течении Y дней.
    - Периодически проводить семинары для Z сотрудников не реже S дней в квартал
    Все что за пределами этого (и не входит в гарантийные обязательства) - прописывается и категоризируется. Отдельно прописываются права третьих лиц за отдельные виды работ (например, возможность нанимать внештатных инженеров).

    Также совет - попросите у знакомых (лучше работающих в иностранных конторах) анонимайзированные (персональные и юр/фин данные забиты ИВан Иванычами и *) договоров продажи ПО с прописанными SLA, приложениями (категории и виды доп работа, бланки-заказов, актов и т.п. - сразу станет понятнее.
    Ответ написан
    1 комментарий