Задать вопрос

kfuntov

Ответы пользователя по тегу Базы данных

  • Какая самая простая для понимания реляционная БД?

    @kfuntov
    Более-менее распространённых реляционных баз данных сейчас не так много:
    Oracle DB и Microsoft SQL Server - точно не подходят под "простые". Это большие enterprise решения, на обучение которым люди тратят уйму времени.

    SQLite - Вы просили не писать (хотя под определение "простая, логичная и понятная" подходит как нельзя лучше: нету пользователей и ещё части усложняющей функциональности, при этом достаточно неплохо выдерживает SQL стандарт)

    MySQL - самая популярная бд, согромным количетвом примеров, советов и т. п. Причём на всех языках мира.
    Сама по себе эта бд не является образцом логичности и простоты, но если ты сталкиваешься с ней каждый день в течении нескольких лет, то она "вдруг" становится понятнее остальных.

    PostgreSQL - сама по себе логичная и приятная, но далеко не простая. Функциональности очень много, причём много сложной.

    Тут есть неплохое "сравнение" (скорее описание общих отличий) SQLite MySQL и PostgreSQL.

    Про менее распространённые:
    Не очень понятно, что вообще надо. Вопрос очень абстрактный. Если надо не только простую, понятную и логичную, а ещё, чтобы разобраться можно было, то надо, чтобы было хоть сколько-то материала (ответов на вопросы, примеров, туториалов).
    Вот страница русской вики (в списке не только реляционные, их пропускал)
    Посмотрим на те, у которых есть хотя бы страничка в русской wiki. (Если нет даже страницы, то вряд ли на русско-язычном ресурсе эту бд кому-нибудь посоветуют). Заранее прошу прощения за пробегание по верхам (с большинством бд не работал, мог допустить неточности):
    * Caché - "позиционирующаяся производителем как «объектно-реляционная» или «постреляционная»" - вряд ли "простая и понятная"
    * DB2 и Informix - базы данных, о которых я даже не смог понять, простые они, или нет. Обе - продукты IBM. Может быть она из них - то, что нужно (я правда не разобрался).
    * Ingres - предшественник PostgreSQL (не вижу смысла иметь дела с ней, когда есть Postgre)
    * mSQL - уже не разрабатывается, была вытеснена MySQL
    * Btrieve - уже не разрабатывается
    * ЛИНТЕР - уже не разрабатывается
    * Adaptive Server Enterprise - не является бесплатной (дальше лень смотреть, если честно)
    * Microsoft Access - комментарии излишни
    * OpenOffice Base - думаю, что так же, как и Access - годится для офис-менеджеров
    * Rdb - предшественник Interbase, хрен поставишь на ПК
    * Interbase - предшественник Firebird
    * Firebird - кстати, достаточно известная база данных, вполне может по соперничать с MySQL и пр. После изучения дополнительной информации о ней, может быть даже посоветовал бы её, как не такую сложную, как Postgre, но и не отход от стандартов и кашу MySQL (хотя сам с Firebird не работал, может оно там ещё сложней и замороченей)
    * HSQLDB - выглядит как маленькая, лёгкая бд, которая хорошо поддерживает стандарты SQL и всё. То есть вполне подходит под определение простая, но достаточно близка к почему-то заранее отклонённой SQLite

    Как итог напишу сложившееся общее субъективное мнение:
    Лёгкие и (поэтому) простые - SQLite (проще работать с базой, больше информации), HSQLDB (работает согласно стандартам SQL).
    Много информации, много возможностей, логичная - PostgreSQL.
    ОЧЕНЬ много информации, достаточно простая, не логичная во многом - MySQL.
    Достаточно простая, сравнительно мало информации, достаточно логичная (вообщем везде средняя) - Firebird.

    P.S. Пока исследовал интернет совсем забыл про то, что в вопросе было про наличие удобных инструментов. По этому пункту
    MySQL получает 5
    PostgreSQL - 4
    SQLLite - 4
    Firebird - 4
    HSQLDB - 3
    Ответ написан
    2 комментария
    2 комментария

  • Топ игроков. Как вывести место конкретного игрока?

    @kfuntov 
    SELECT score,
       (SELECT COUNT(*)
          FROM table AS p
         WHERE p.score <= t.score) AS position
 FROM table AS t WHERE id=@id;


    По мотивам stackoverflow.com/questions/3614666/mysql-get-row-...
    Ответ написан
    4 комментария
    4 комментария

  • Как правильно получить суммирующую таблицу из двух?

    @kfuntov
    Все валюты есть в обоих таблицах? Или какой-то из валют где-то может не быть?
    Если в ПРИХОДАХ есть все виды валют, то можно так:
    SELECT
       p.валюта as ВАЛЮТА,
       p.tot as ПРИХОДОБЩИЙ,
       r.tot as РАСХОДОБЩИЙ,
       (p.tot - r.tot) as ОСТАТОК
FROM 
    ( SELECT SUM(приход) as tot, валюта FROM ПРИХОДЫ GROUP BY валюта ) as p
  LEFT JOIN 
      ( SELECT SUM(расход) as tot, валюта FROM РАСХОДЫ GROUP BY валюта ) as r
     ON r.валюта = p.валюта


    Если в "ПРИХОДАХ" может не быть каких-то валют,то нужен FULL JOIN, вместо LEFT.
    MySQL его сама не умеет, но способов его реализовать несколько, например:
    UNION LEFT и RIGHT JOIN-ов - самый короткий/понятный/красивый вариант, но при большом количестве валют может начать тормозить, так как UNION делает сортировку.
    SELECT
       p.валюта as ВАЛЮТА,
       p.tot as ПРИХОДОБЩИЙ,
       r.tot as РАСХОДОБЩИЙ,
       (p.tot - r.tot) as ОСТАТОК
FROM 
    ( SELECT SUM(приход) as tot, валюта FROM ПРИХОДЫ GROUP BY валюта ) as p
  LEFT JOIN 
      ( SELECT SUM(расход) as tot, валюта FROM РАСХОДЫ GROUP BY валюта ) as r
     ON r.валюта = p.валюта
UNION
SELECT
       p.валюта as ВАЛЮТА,
       p.tot as ПРИХОДОБЩИЙ,
       r.tot as РАСХОДОБЩИЙ,
       (p.tot - r.tot) as ОСТАТОК
FROM 
    ( SELECT SUM(приход) as tot, валюта FROM ПРИХОДЫ GROUP BY валюта ) as p
  RIGHT JOIN 
      ( SELECT SUM(расход) as tot, валюта FROM РАСХОДЫ GROUP BY валюта ) as r
     ON r.валюта = p.валюта

    Если производительность в данном месте требует оптимизации (советую сильно подумать, прежде, чем отвечать "да"), то можно усложнять запрос, делая его быстрее.
    Например, заменить UNION на UNION ALL и во второй части не выбирать значения, которые есть в первой.
    Ответ написан
    3 комментария
    3 комментария