Ответы пользователя по тегу MySQL
  • Как правильно спроектировать базу данных для сайта?

    syschel
    @syschel
    freelance/python/django/backend
    Мне кажется вы немного перемудрили, излишне усложнив.
    Смотря на ваше "меню", как вижу таблицы в БД я:
    + pages = id, url(ЧПУ, если выводить в адресной строке хотим не ИД), title(заголовок), text(тело страницы, то есть текст)
    + news = id, url, date, title, short_text(этот текст выводим в списке новостей, он короткий), text(это уже на странице новости), image(картинка новости)
    + photo_category(если нужны альбомы для набора фотографий) = id, title, text(описание альбома), image(превьюшка альбома)
    + photos = id, name(если нужно название или описание), image(путь до файла), category(ссылка на photo_category, если нужны альбомы, иначе поле не создаём)
    + videos = id, video(ссылка на видео файл)
    + document_category = id, name
    + documents = id, category(ссылка на document_category ), ISBN(какой-то идентификатор документа вне бд), created(дата_тайм создания), update(дата_тайм обновления/изменения)

    Если изменений у документов несколько, в разные периоды, то я бы выносил поле update в отдельную таблицу
    + document_modifed = id, document(ссылка на документ), date, comment(комментарий иб изменениях, если он нужен)

    Ещё можно было бы добавить пользователей, пускай не на уровне пользователей сайта, а просто как список, то добавил бы. Чтобы указывать автора документа, автора изменений документа(если это нужно отслеживать).

    Поля category в таблице photos и document_category , у меня подразумевают, что категория у них может быть выбрана одна из, а не множество из. Если нужно именно множественный, то да, создавать отдельную таблицу и указывать там связи
    Я сделал специально независимые таблицы "категорий", так как скорее всего они и будут независимыми, не пересекающимися. Тогда при создании под объекта, можно выбирать из списка категории только его типа, а не копаться во всех категориях скопом. То есть, создавая запись об документе, не надо выбирать среди "фоточки с корпаратива 2018", "протяжные валы", "зарплаты", "отмечаем юбилей", "отчёты".
    Ответ написан
  • Как сделать тяжелый импорт из excel 800к товаров?

    syschel
    @syschel
    freelance/python/django/backend
    1. У вас именно EXEL файл или всётаки CSV который вы открываете на десктопе с помощью экселя?
    2. Если всётаки EXEL файл. Там слишком много всего нагорожено, на вроде вёрсток и формул или голые таблицы?
    3. Если всётаки голые таблицы. Вы можете делать именно CSV файл?

    Если данные будут в CVS формате, то можно всё загрузить средствами MYSQL и не использовать для обработки PHP или его библиотеки. Тогда результат будет в разы выше, чем если перебирать с помощью ПХП и потом кормить в MSQL

    Когда я в своё время сталкивался с проблемой загрузки файла товаров в базу, там было несколько миллионов единиц, то оптимальным стало именно такое решение > LOAD DATA

    Кусок моего старого MySQL кода, для наглядности
    // Загружаем кашерный файл
    LOAD DATA LOCAL INFILE '/srv/cms_cpa/files/adimport_items.csv' INTO TABLE adimport_tmp CHARACTER SET utf8 FIELDS TERMINATED BY '|' ENCLOSED BY "'" LINES TERMINATED BY '\n' IGNORE 1 LINES (id_adimport,article,available,currencyId,delivery,description,id,name,oldprice,param,picture,price,url,vendor,advcampaign_id,advcampaign_name);
    
    // Загружаем только нужные поля (!!!)
    LOAD DATA LOCAL INFILE '/srv/cms_cpa/files/adimport_items.csv' INTO TABLE adimport_tmp CHARACTER SET utf8 FIELDS TERMINATED BY '|' ENCLOSED BY "'" LINES TERMINATED BY '\n' IGNORE 1 LINES (id_adimport,@ISBN,@adult,@age,article,@attrs,@author,available,@barcode,@binding,@brand,@categoryId,@country_of_origin,currencyId,delivery,description,@downloadable,@format,@gender,id,@local_delivery_cost,@manufacturer_warranty,@market_category,@model,@modified_time,name,oldprice,@orderingTime,@page_extent,param,@performed_by,@pickup,picture,price,@publisher,@sales_notes,@series,@store,@syns,@topseller,@type,@typePrefix,url,vendor,@vendorCode,@weight,@year,advcampaign_id,advcampaign_name,@deeplink);
    
    // Все поля
    LOAD DATA LOCAL INFILE '/srv/cms_cpa/files/adimport_items.csv' INTO TABLE adimport_tmp CHARACTER SET utf8 FIELDS TERMINATED BY '|' ENCLOSED BY "'" LINES TERMINATED BY '\n' IGNORE 1 LINES (id_adimport,ISBN,adult,age,article,attrs,author,available,barcode,binding,brand,categoryId,country_of_origin,currencyId,delivery,description,downloadable,format,gender,id,local_delivery_cost,manufacturer_warranty,market_category,model,modified_time,name,oldprice,orderingTime,page_extent,param,performed_by,pickup,picture,price,publisher,sales_notes,series,store,syns,topseller,type,typePrefix,url,vendor,vendorCode,weight,year,advcampaign_id,advcampaign_name,deeplink);

    Ответ написан
  • Автоудаление, чистка записей в БазеДанных?

    syschel
    @syschel
    freelance/python/django/backend
    у меня 2 таблицы, в рдну я пихаю адреса зарегистрированных пользователей, в другую, адреса тех кто покупает без регистрации. таким образом адрес привязан только к этому заказу, как потом автоматически удалить его из БД? и правильно вообще так делать?

    Смотря что за магазин. Если реальный и живой с претензией на рост, то удалять ничего нельзя. Нужно будет для маркетологов статистику собирать. Графики для продажников рисовать.
    Адрес доставки можешь хранить в заказе, а можешь в юзере. Можешь авторегистрировать юзера по данным из заказа. Возможно ты захочешь приветствовать старого юзара, начислять бонусы, вести историю или начать предугадывать корзину. Много вещей куда нужны данные если магазин будет расти и он реален.
    Если же это просто тестовая среда разработчика или на какой-то джумле поднят магазин, то без разницы, всёравно ты через пол года его удалишь.

    Можешь связи каскадные установить на таблицы (при удалении одной записи удаляются все связанные).
    Можешь триггеры написать на события.
    Можешь эвенты написать.
    Можешь отдельную команду на крон повешать с запуском по таймеру раз в день, неделю, месяц, год на удаление "старого".

    Вообще, удалять "старое" и "не нужное", как я заметил, это маниакальная идея всех новичков. Для большой БД лучше если записи не будешь трогать а оставишь на месте, чем удалять постоянно. Крупные ресурсы обычно симулируют удаление, просто введя поле delete или подобное в каждую таблицу, а по нему отображают или нет.
    Ответ написан
  • Создание веб-страниц сайта на базе готовой БД. Как?

    syschel
    @syschel
    freelance/python/django/backend
    Вот здесь лежит цмс, которая вам нужна. Другого решения нету.
    Ответ написан
  • Будет ли работать mysql с нагрузкой примерно триллион записей?

    syschel
    @syschel
    freelance/python/django/backend
    Проблема врятли будет в самой базе данных. Как правило всё упирается в три вещи:
    1. Сами запросы и оптимизация их.
    2. Конфигурация базы данных и самого сервера. Ну и правильно расставленные индексы.
    3. Ресурсы сервера с базой данных.
    Ответ написан
  • Как раскидать значения в столбце в MySql?

    syschel
    @syschel
    freelance/python/django/backend
    Организация конечно не ахти. Проще сразу бы добавить второе поле даты завершения.
    А так, если при смене статуса пишется ещё одна строка с общим идентификатором object_id. То делать COUNT('object_id') as count GROUP BY object и все результаты где он будет больше 1 игнорировать.
    Ответ написан
  • Как создать-настроить триггер в mysql?

    syschel
    @syschel
    freelance/python/django/backend
    Вы базу убьёте. При наплыве пользователей и их активности, у вас очередь будет из сотен "триггеров" на обновление всех пользователей. По вешайте лучше на крон пересчёт каждые N минут.

    Добавлю, по вашей логике. Триггер запускается когда идёт обновление таблицы юзера. И вы хотите сразу же запустить массовое обновление всех юзеров. Что вызовет по каждому юзеру новую волну обновлений. Вечный цикл.
    Ответ написан
  • Как взять айди из бд, пользователя который сейчас в сессии?

    syschel
    @syschel
    freelance/python/django/backend
    Тут смотреть только в ту часть кода, которая отвечает за авторизацию. И дорабатывая её, а уже с этим воевать.
    Просто так, зашёл и получил список пользователей онлайн, только на основании, что у них открыта сессия, нельзя. Или писать мега великий бубен с чтением файлов сессии с HDD сервера. Но их никто не писал никогда и не пишет. Только если какой "хакер", получил доступ к чужому сайту и хочет "подсмотреть" кто из пользователей онлайн. Да и то не будет заморачиваться таким способом.
    Дорабатывают систему авторизации обычно, через дататайм авторизации и последующем его обновлением при гуляние по сайту. А потом смотрят, кто авторизировался за последние 5-10-15 минут.
    Ответ написан
  • Как (и можно ли) добавить в таблицу поля с вычисляемыми именами на голом MySQL?

    syschel
    @syschel
    freelance/python/django/backend
    copist: Не очень понятно, что конкретно должно быть в колонках name_1 name_2

    0lorin: В будущем — названия стран на языках из первой таблицы.

    То есть при появлении новой записи в languages, в таблице countries добавить поле равное `name_` + languages.id?
    Отвечу, что нельзя голым майскулом. :-)
    Потому что автосоздание вы можете по вешать по сути только на тригер. А он не дружит со склейкой имён полей из переменных(CONCAT). Сам с этим воевал. Пробовал даже создать функцию, которая бы обращалась к полю, имя которого должно собираться из составных частей. Но триггеры послали меня в лес, сказав что «хитрый какой, мы видим что ты в функции создаёшь поле из переменных».
    Ни создать, ни даже обратиться к такому полю.
    Если же создание поля будет у вас выполнять php, а не MySQL, то там вариант niko83 вам подойдёт.

    Но я бы всё таки сделал как советует boodda. С годами пришёл именно к такому варианту. Особенно когда начал использовать ОРМ джанги. Просто на HL проекте не стоит всё завязывать на MySQL. Многие вещи, особенно если это списки. Порой проще вытаскивать из БД и перебирать уже кодом. Ну и для обработки больших списков помогают такие вещи как MongoDB или noSQL
    Ответ написан