• В чем преимущества СУБД Oracle перед MySQL, PosgreSQL?

    @Vasily_Pechersky
    Системщик с опытом
    Тут можно сказать две вещи:
    1: Как и Windows - первый, значит самый известный и все думают, что лучший .....
    2: Реально - В Oracle есть пара фишек (из тех, что я знаю), которые очень актуальны в БОЛШИХ и ОЧЕНЬ БОЛЬШИХ базах данных. К примеру - Oracle RAC - быстро разворачиваемый кластерный доступ к базе данных. Плюс оптимизация использования кучи процессоров и моря памяти.

    Так же Станислав Макаров дал очень актуальный ответ.
    Но сейчас, в связи с обилием на рынке огромного выбора технологий баз данных, которые специализируются под решение разных задач - плюсы от использования Oracle DB мне кажутся сомнительными, учитывая цены на покупку и поддержку (ценовая политика компании Очень гадкая)
    Ответ написан
    1 комментарий
  • В чем преимущества СУБД Oracle перед MySQL, PosgreSQL?

    sim3x
    @sim3x
    MySQL это для школьников и блокнотиков
    а еще для танчиков WoT, где варгейминг хранит 400Гб данных пользователей
    // правда не в мускуле, а марииДБ

    А яндекс уходит от Оракла на постгрес, тк оракл не дает своих исходников, а им очень хочется посмотреть почему у них все тормозит

    Тот кто дорос да уровня
    профи
    вообще очень осторожно относится к понятию
    только Х
    Ответ написан
    Комментировать
  • В чем преимущества СУБД Oracle перед MySQL, PosgreSQL?

    @wani
    Начнем с того, что Oracle DB - это платное решение (следовательно Oracle все свои усилия будет вкладывать в этот проект), а MySql - бесплатное (Open Source). В Oracle DB есть процедурный язык Pl/Sql, который позволяет производить обработку данных на уровне БД. В MySql такое тоже есть, но оно не на таком уровне как в Oracle DB. + ко всему вокруг Oracle DB создана целая инфраструктура.
    Ответ написан
    1 комментарий
  • В чем преимущества СУБД Oracle перед MySQL, PosgreSQL?

    azrail_dev
    @azrail_dev
    Cлииишком субъективное мнение, но на работе юзаем oracle?=)))
    Ответ написан
    Комментировать
  • Вопрос по Sphinx. Можно ли реализовать фасетный поиск по такой структуре?

    opium
    @opium
    Просто люблю качественно работать
    а смысл сюда крутить сфинкс, на десять тысяч записей оно будет летать и на мускуле.
    Ответ написан
    2 комментария
  • Чем в Магенто отличаются "маленькое изображение" и "миниатюра"?

    «Маленькое изображение» («small image») отображается на витрине в списке товаров
    656a910899ba4aaa8deb53b2315b8be2.png

    «Миниатюра» («thumbnail») отображается на витрине во многих местах, например:
    в корзине:
    fe9ab98f004f466781099df4662e7edc.png

    под основной фотографией товара:
    af2947a7dcc94c61851e56e6f93035c2.png

    и т.п.

    Вообще, проблема стандартного пакета русификации с Magento Connect в том, что человек, делавший его, не вполне понимал, как работает Magento. Видимо, перед ним был просто список строк для перевода, и он переводил их механически, не особо вникая, как это всё реально устроено в Magento.

    В Российской сборке Magento я постарался сделать русификацию как можно более осмысленной, там таких вопросов с интерфейсом возникать не должно:
    0f3c73a287e0407b9298b4f96205857f.png
    Ответ написан
    1 комментарий
  • Как добавить товар в корзину?

    Вам уже посоветовали использовать json, я попробую дать более общую рекомендацию. У вас стандартная для вашей предметной области проблема - отсутствие единой схемы данных, у вас имеющихся. Очень редко в работающем приложении кто-либо меняет схему "на ходу" - т.е. в 99% случаев схема (по кр. мере логическая) проектируется вместе с приложением. Новая версия приложения - новая схема (при необходимости, конечно). Таким образом, ваша задача диктует вам необходимость работать с ЧАСТЬЮ ваших данных без использования схемы. Согласитесь, это не очень гибко - заводить новую таблицу под каждый вид товара, коих огромное количество может быть. Самое главное, новые товары приходят каждый день, и каждый день добавлять таблицы - с ума сойдешь. И совершенно непонятно, как при этом разрабатывать SQL-запросы на выборку, учитывая все новые и новые таблицы.
    Т.о., часть данных вам лучше хранить иначе, а именно атрибуты ваших товаров. Тут подхода два: это либо полуструктурированные данные (semistructured), т.е. XML или JSON, либо EAV модель. Последняя является классическим выходом из ситуации при использовании реляционных баз данных, однако т.к. она по определению идет в разрез с реляционной структурой данных - это все по сути большой костыль. Сегодня все чаще рекомендуют первый вариант, т.к. во-первых многие современные РСУБД поддерживают JSON или XML типы данных, причем даже с возможностями валидации и выборки (а если и нет - BLOB всегда поможет), а во-вторых под каталог товаров можно использовать любую документную базу данных, которая кстати еще и лучше подойдет по специфике нагрузки на каталог (очень много чтения и мало записи, целостность не особо нужна - шардинг будет без особых проблем).
    Итого:
    1) понимаете, почему не все данные не всегда получается уложить в фиксированную схему
    2) выбираете себе подходящее решение из перечисленных, помня, что можно (и нужно!) часть данных хранить в нормализованном виде, а часть - не получится.
    3) поиск и выборка по ненормализованным данным рассматривается как отдельная задача
    P.S. вот как раз таки в корзину достаточно класть ID товара и его количество, что отлично уложится в реляционную схему. А для этого таблица товаров одна должна быть.
    Ответ написан
    8 комментариев
  • Как вернуть диалог выбора Операционной Системы?

    @vano666
    Используй очень простую и удобную программу EasyBCD, она проверяет разделы на наличии ОС и позволяет добавить их в список загружаемых через загрузчик ОС.
    Скачать можно по ссылке soft.oszone.net/download/4063/EasyBCD.html
    Ответ написан
    Комментировать
  • Вопрос по Acronis True Image, действительно ли бэкап полный?

    service_man
    @service_man
    Работаю над ServiceSpeedUP.com
    Объем резервной копии зависит о степени сжатия которую вы установили, в некоторых случая он не включает туда временные файлы. Сушествует только один способ проверить работоспособность бэкапа - развернуть его на компьютере. Акронис это одна из лучших программ для бэкапа, но и у нее бывают сбои.
    Ответ написан
    Комментировать
  • Вопрос по Acronis True Image, действительно ли бэкап полный?

    eapeap
    @eapeap
    Сисадмин, Беларусь
    Нужно делать образ диска и MBR - загрузчика. Тогда всё будет ОК.
    Объем образа да, меньше.
    Ответ написан
    9 комментариев
  • Вопрос по Acronis True Image, действительно ли бэкап полный?

    like-a-boss
    @like-a-boss
    Признайся,тебяТянетНаКодМужика,ты—программный гей
    Помнится, когда я делал образы акронисом, размер образа был меньше занятого пространства диска, так что всё норм) Для уверенности повторите процедуру :)
    Ответ написан
    Комментировать
  • Может ли кто-нибудь объяснить суть паттерна проектирования "One True Lookup Table"?

    @AdvanTiSS
    Это не паттерн а антипаттерн. Заключается в том, что новички зачастую используют одну универсальную таблицу для хранения сущностей разных типов.

    Идея: вместо использования трех лукап таблиц
    create table order_status (status_code varchar2(10), status_desc varchar2(40) );
    create table country (country_code varchar2(3), country_name varchar2(30) );
    create table priority (priority_no number(1), priority_desc varchar2(40) );


    Почему бы не использовать одну таблицу в виде
    create table lookup (
    lookup_type varchar2(10), 
    lookup_code varchar2(20), 
    lookup_desc varchar2(100) );

    Подробности тут tonyandrews.blogspot.cz/2004/10/otlt-and-eav-two-b...
    Учите английский, без него туго будет.
    Ответ написан
    Комментировать
  • Для каких задач больше подойдет MySQL а для каких PostgreSQL?

    un1t
    @un1t
    Задачи примерно одинаковые. Для интернет магазина подойдет любая. Обе СУБД проверенны временем и используются в том числе на крупных и highload проектах.
    Для дешевых сайтов лучше MySQL, т.к. есть на любом хостинге. Т.е. если вы пишите коробочную CMS на PHP, то лучше MySQL. Если облачный конструктор сайтов, то без разницы.

    MySQL поддерживает и транзакции и полнотекстовый поиск и гео данные, но что-то релизовано в движке MyISAM, а что-то в InnoDB. Т.е. если нам надо и то и то, то придется юзать разные движки на таблицы, а это ломает например ссылочную целостность. В простгресе один движек и все это есть.

    У MySQL еще некоторое время назад был самый топорный, читай медленный алгоритм join'ов. В этом плане Postgres был впереди. Ну как впереди, он давал преимущество на коряво написанных приложениях с большим количеством join'ов. Можно ли считать это преимуществом вопрос. Но в последний версиях MySQL 5.6 появились более быстрые виды join'ов. Лично мне это все до лампочи, потому что join'ы во первых были медлеными, а во вторых не масштабируются, поэтому я их не использовал. Да и Django умеет делать быстрый джойн на уровне приложения простым методом ORM - prefetch_related.

    JSONB - технология Postgres, которая позволяет сохранять JSON в таблицу. Я бы не назвал это особым преимущестовм, в MySQL хоранить JSON не проблема, в обычно текстовом поле, только обработку делай на уровне приложения и все. В Джанге, опять же это делается установкой какой-нибудь батарейки django-jsonfield или написанием 15 строчек кода единоразово. Т.е. явно сильного преимущества тут нет, тем более, что такие штуки в любом случае удобнее в Монге хранить.

    Массивы в Postgres. Было бы прикольно, если бы могли не только хранить, но и строить по ним индекс, как в Монге. Но нет, Постгрес предлагает строить по ним полнотекстовые индексы. Ну а если речь идет про полнотекстовый поиск, то на любом большом сайте уже есть поисковый движек, например Sphinx или ElasticSearch, соотвестваенно, я могу масивы и в MySQL серелизовать в строку и индексировать их этим движком.
    Тут преимущество явно на стороне Монги (хотя ее мы тут не рассматриваем), Постргесу еще расти.

    Постгрес умеет строить индексы по XML и видимо JSON. Подумаешь, если какая уже говорил, у нас на проекте есть полнотекстовый движек, то мы можем построить индекс по чему угодно и без Постгреса.

    Полнотекстовый поиск. Вот тут у Postgres действительно есть преимущество как перед MySQL, так и перед MongoDB. Постгрес подерживает русский язык на уровне стемминга, что во многих случаях волне достаточно. Если надо морфологию, то уже поисковые движки надо использовать, а не БД. MySQL не поддерживает языки, а MongoDB поддерживает русский, но не поддерживает оператор AND (блин как это вообще может быть?!).

    Вобщем пока таким явным преимущестовм Постгреса я вижу полнотекстовый поиск, для проектов в которых почему-то нет полноценных полнотекстовых движков. Но с установкой любого движка, это преимущество исчезает.
    Ответ написан
    6 комментариев
  • Для каких задач больше подойдет MySQL а для каких PostgreSQL?

    voidnugget
    @voidnugget
    Программист-прагматик
    Прежде чем холиварить нужно разъяснить 3 вещи
    1. Модель БД в 6ой нормальной форме могут проектировать единицы
    2. Понимать как все эти схемы, каталоги, представления и материализованные представления вписываются в SOA, как производить тестирование, какие функции где хранить, как проставлять тригеры, как подчищать журналы, как разделить представления чтения/записи в рамках CQRS - знают единицы, а использует на практике и того меньше.
    3. PostgreSQL можно сделать быстрее и эффективнее чем MySQL / MongoDB / Oracle, но не наоборот, хотя косячить можно везде :), и там много чёрной магии которая простым смертным просто недоступна. PostgreSQL слишком просто кастомизируется, и этим можно получить просто дикие приросты производительности, особенно если речь идёт о внедрении каких-то кастомных типов данных, индексов и функций агрегации. В остальных решениях "шаг вправо, шаг влево - расстрел". Если вам нужно простое решение которое "лишь бы работало с коробки" - вам точно не стоит использовать PostgreSQL.
    Ответ написан
    1 комментарий
  • Для каких задач больше подойдет MySQL а для каких PostgreSQL?

    SowingSadness
    @SowingSadness
    web-разработчик
    PostgreSQL лучше во всех аспектах, в том числе и по скорости ответа.
    Уже нет причин использовать MySQL.

    PostgreSQL можно продавать со своим продуктом. MySQL - нет.
    PostgreSQL умеет массивы, MySQL - нет.
    PostgreSQL умеет json, MySQL - нет.
    PostgreSQL умеет DateTime с временными зонами, MySQL - нет.
    PostgreSQL умеет работать с временными интервалами, MySQL - нет.
    PostgreSQL умеет нормально работать с unicode, MySQL - нет.
    PostgreSQL умеет DISTINCT по выбранным колонкам, MySQL - нет.
    PostgreSQL умеет ограничивать значения индексов по условиям, MySQL - нет.
    PostgreSQL имеет схемы, MySQL - нет.
    PostgreSQL имеет наследование в таблицах, MySQL - нет.
    PostgreSQL есть нормальная оптимизация JOIN, MySQL - нет.
    PostgreSQL умеет материализованные представления, MySQL - нет.
    PostgreSQL умеет PLSQL, MySQL - нет.
    PostgreSQL умеет Python функции, MySQL - нет.
    PostgreSQL умеет ключи из внешних источников, MySQL - нет.
    PostgreSQL умеет нормальные(вложенные) транзакции, MySQL - нет.
    MySQL есть проблемы с установкой и удалением своих сервисов под Windows, PostgreSQL - нет.
    ̶P̶o̶s̶t̶g̶r̶e̶S̶Q̶L̶ ̶у̶м̶е̶е̶т ̶а̶с̶и̶н̶х̶р̶о̶н̶н̶у̶ю р̶е̶п̶л̶и̶к̶а̶ц̶и̶ю̶, ̶M̶y̶S̶Q̶L̶ ̶-̶ ̶н̶е̶т.
    Ответ написан
  • Почему Магенто пишет "категории нет в наличии"?

    Сообщение на витрине «категории нет в наличии» означает, что у текущего магазина (отображаемого на витрине) многомагазинной системы Magento отсутствуют товарные разделы.
    Из того, что в административной части есть какие-то товарные разделы, не следует, что эти товарные разделы привязаны к текущему магазину.
    Чтобы привязать товарные разделы к конкретному магазину, надо обязательно сделать их подразделами корневого раздела данного магазина.
    Корневой раздел, в свою очередь, должен быть привязан к данному магазину в административном разделе управления магазинами (в Российской сборке Magento это делается в разделе «Система» → «Магазины»).
    Ответ написан
    Комментировать
  • Как вникнуть в тонкости back end разработки?

    Stac
    @Stac
    Серверные скрипты в своем простейшем случае (PHP, Perl, CGI-скрипты на любых других языках) весьма похожи на неинтерактивные консольные программы (утилиты командной строки).

    Они принимают данные на вход через заголовки и тело HTTP-запроса, что-то быстро делают и выводят результат [в браузер].

    PHP или CGI-скрипт вызывается вебсервером (программой) в процессе отбработки входящего запроса (request) . Он же получает результат работы скрипта и фактичеки возвращает браузеру в ответном HTTP-запросе (response).

    HTTP-запросы это чистый текст с минимальной структурой, с которой имеет смысл ознакомиться.

    В некоторых технологических стеках сама прикладная программа и является вебсервером (например, node.js и Ruby On Rails - впрочем, не влададею эти технологиями, могу ошибаться).
    Но даже в этом случае прикладной программист не работает пакетами и битами (может, если захочет, но на практике это не нужно).

    Прикладная среда выполнения (вебсервер или фреймфорк), приняв запрос, дает программисту доступ к его элементам через глобальные переменные или объекты, в зависимости от того, как принято в конкретном языке программирования.
    Для PHP это глобальные переменные (ассоциативные массивы) $_SERVER, $_REQUEST и др. В первой можно найти некоторые HTTP-заголовки, кое-какие данные о сервере и удаленном клиенте (IP адрес, например). Во второй собраны все входные данные, переданные через URL (site.ru/page.php?key=value&key2=value2), в теле POST запроса, через куки (фактически HTTP-заголовки специального формата) и переменные окружения [операционной системы].

    Различные фреймворки могут иметь классы и объекты с именами типа Request.

    Для хранения данных на компьютере используются ... та-дам... файлы. Их можно писать и читать, и работает это достаточно быстро (файловая система сама обеспечивает буферизацию и кэширование).

    Если данных очень много и их не просто надо читать, но для начала найти какие-то фрагменты (конкретные строки таблицы, поля объекта) по каким-то критериям, а потом, возможно, как-то обработать, то можно использовать СУБД.

    СУБД бывают встроенные и клиент-серврные.
    Пример встроенной это SQLITE, которая встроена в PHP как модуль расширения. Она также используется в iOS, Android, браузерах Firefox, Chrome и многих-многих других программах.

    Клиент-серверные чаще всего это MySQL (даже чаще чем надо), PostreSQL, MS SQL Server, Mongo DB, есть куча других.

    Серверная часть такой СУБД работает как отдельный сервер (программа), возможно на отдельном сервере (компьютере). Клиентская часть это модуль в среде исполнения (расшириние PHP, библиотека функций) или может условно отсутствовать, если СУБД имеет HTTP API. В этом случае клиентскую часть пишет прикладной программист на своем языке.

    Случай с выделением хранилища данных на отдельный компьютер с возможным последующим масштабированием серверов или клиентов (один сервер - много клиентов, много серверов - один клиент, много серверов - много клиентов) это второй случай, когда реально стоит использовать БД (первый, напомню - необходимость хитрой выборки и обработки хранимых данных).

    В PHP-практике, наоборот, самый популярный сценарий это "один сервер - один клиент" и на одном компьютере. Так сложилось исторически.
    Так работают самые популярные CMS, так пишутся книги, проводятся курсы.

    Все операции на сервере происходят по необходимости, мы открываем соединение с БД по необходимости, принимаем запрос по необходимости, говорим что переменая имеет тип int unsigned исходя из необходимости.


    Нет какой-то абстрактной необходимости. Первопричина всего (на прикладном уровне) - входящий запрос. Вебсервер ожидает постоянно входящие запросы (слушает TCP-порт).
    Вот запрос пришел. Сервер согласно своим настройкам определяет, может ли он сам его обработать (например, "отдать статику") или он должен передать запрос другому обработчику по цепочке. Таким обработчиком может быть, например, PHP.
    Вебсервер запускает интерпретатор PHP и передает запрос ему.
    PHP определяет (в общем, по ссылке, которая есть в параметрах запроса), какой PHP-скрипт надо выполнить, ищет его и выполняет. Результат работы скрипта - HTTP-response (фактичеки это plain text, содержащий служебные заголовки, в т.ч. куки и тело с HTML / XML / JSON, etc. ) - отдается обратно вебсерверу, он возвращает его туда, откуда пришел запрос (на IP адрес и порт), часто в браузер.

    В других технологических стеках алгоритм обработки HTTP-запроса может отличаться от описанного. Как правило, чем больше он отличается, тем лучше этот стек, чем PHP (в смысле производительности).

    Мы, прикладные программисты, не опускаемся ниже HTTP-протокола. А используя фреймворки, даже HTTP можем не касаться, хотя знать и понимать его надо.
    Т.е. до всех этих TCP-портов и настроек сервера нам, как праивило, дела нет (пока все работает).
    Первое - удел скорее системных программистов, второе - сисадминов или модных ныне девопсов.

    Что почитать, чтобы лучше понять операции на бэке, которые не поймешь сразу ...


    Еща раз-два прочтите мой ответ. Если не помогло - возьмите любую книжку по PHP. В начале должно быть описано взаимодействие браузера и вебсервера. Потом и про язык можно чуть-чуть почичать.

    Сейчас PHP все еще самый простой путь в back-end разработку. А раз вы упоминаете про int unsigned, то вам будет привычен и его Си-подобный синтаксис. Типа данных такого, однако, в PHP нет.
    Ответ написан
    2 комментария
  • (Yii2) Как сохранить сразу несколько строк в базу?

    @hector
    php программист
    Если не использовать AR, то batchInsert()
    Ответ написан
    Комментировать