Добрый вечер надеюсь на вашу помощь. Объясните как реализовать базу данных как в этом проекте http://www.slader.com/textbook/9780538497817-stewart-calculus-7th-edition/ Смысл там вот в чем есть книга в книге несколько глав в каждой главе несколько тем в каждой теме по несколько задач. Какие таблицы создать и сколько создать чтобы было легче вызывать foreach ом, ведь там меню 2вух уровней

Так а что дерево мешает построить ?

как опишите по подробнек

как опишите по подробнек

https://habrahabr.ru/post/193136/

Кстати вот https://habrahabr.ru/post/348854

он толстый как падла если хранить нативно

я думаю поэтому убер schemaless используют

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

И никак этого не избежать. Разве что изначально проектировать каким то образом без всего этого

Ну есть же частичные индексы

Не везде конечно

ну вот как раз индекс поверх generated columns это оно и есть

если говорить про mysql

Частичные индексы иногда приводят к гораздо большим нагрузкам.

Нет в нормальных базах не нужны отдельные колонки

Вчера сидел измерял миксованые индексы. Там хоть книгу пиши о извращеных разрабах

50 оттенков индекса

Миксованые индексы с полнотекстовым поиском. Эластик как бэкэнд для такого изврата

Ужос

Здравствуйте. бд pgsql Есть есть цены с продуктами , задача составить топ цен + изменение цены за сегодня(цена за сегодня - цена за вчера) Что-то я не могу сообразить чем заменить селект в селекте. SELECT id, price, date, (price - (SELECT price FROM price_products y WHERE y."date" = '2018-02-10' AND t.id = y.id)) as price_yesterday FROM price_products y WHERE "date" = '2018-02-11' ORDER BY price Есть ли другой путь ?

"оконные функции не поддерживают where" - это как?

А с чего бы ему их поддерживать, когда оконки работают на основе результата выборки

да, фигню написал

счас удалю

эммм, погодите, хотите сказать, что в постгрес нельзя испоьзовать where в запросе с оконкой?

блин, ответьте на вопрос, по документации не понятно, можно или нет

нет нельзя . ошибку выдает. внутри оконки

стоп, читаю и вижу

The rows considered by a window function are those of the "virtual table" produced by the query's FROM clause as filtered by its WHERE, GROUP BY, and HAVING clauses if any. For example, a row removed because it does not meet the WHERE condition is not seen by any window function. A query can contain multiple window functions that slice up the data in different ways by means of different OVER clauses, but they all act on the same collection of rows defined by this virtual table.

почему нельзя?

мы про разные видимо where. в разных местах

where один

а где вы там додумываете, это уже действительно вопрос

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

т.е. ваше решение, это подзапрос с оконкой, где вы находите прошлую цену, например при помощи lag, а дальше основным запросом фильтруете, на какую дату вынимать данные

спс. понял в какую сторону копать

Здравствуйте, это чат о базах данных?

допустим

жду вопрос про "kde под freebsd"

Про kde вопроса не будет

Уже не мэйнстрим

окей

тогда какой будет?

тогда какой будет?

По сюжету, он должен сейчас спросить где прочитать описание чата...

Есть аццесс с таблицами в одном файле (на сетевой шаре) и файл с формами локально. Ребята жалуются, что медленно работает. Можно ли ожидать увеличения скорости если таблицы в SQL сервер загнать? Пользователя всего 2-3.

Вопрос из разряда 'не кидайтесь тапками' Нужно собрать базу данных игрового мира. Игра с видом сверху, состоит из большого (>10000) количества комнат, соединённых проходами. Нужен быстрый доступ к информации об определенной комнате, удобство использования. В какую сторону копать?

Есть аццесс с таблицами в одном файле (на сетевой шаре) и файл с формами локально. Ребята жалуются, что медленно работает. Можно ли ожидать увеличения скорости если таблицы в SQL сервер загнать? Пользователя всего 2-3.

по теории, да, ибо когда работает по шаре, то действует схема "выкачиваем весь файл с шары", тогда как, если подключить внешний источник MS SQL, то будут браться только необходимые данные

Вопрос из разряда 'не кидайтесь тапками' Нужно собрать базу данных игрового мира. Игра с видом сверху, состоит из большого (>10000) количества комнат, соединённых проходами. Нужен быстрый доступ к информации об определенной комнате, удобство использования. В какую сторону копать?

сбор данных, это совсем другая тема

по теории, да, ибо когда работает по шаре, то действует схема "выкачиваем весь файл с шары", тогда как, если подключить внешний источник MS SQL, то будут браться только необходимые данные

Спсибо, попробуем

сбор данных, это совсем другая тема

?

?

ну скажем так, причем тут базы?

ну скажем так, причем тут базы?

Чтобы хранить

Но я тупой

хорошо, тогда в чем вопрос? как хранить то, что вы собираете?

хорошо, тогда в чем вопрос? как хранить то, что вы собираете?

Возможно в базе данных?

Хранить на сервере

В Германии

эмм, вас понесло

эмм, вас понесло

Давайте на 'ты'

Все ж мы люди

сейчас у вас есть игра и свой какой-то сервер, правильно? у вас есть инструмент, который собирает данные?

сейчас у вас есть игра и свой какой-то сервер, правильно? у вас есть инструмент, который собирает данные?

Сейчас сбор на костылях

Хочу сделать адекватно

То есть сейчас данные в бинарке локально лежат

Это не то

окей, тогда то что собираете, сохраняйте в базу, по теории не вижу преград этого не делать

самим сборщиком можете разрулить, как вам удобнее это сохранять

То есть выигрыша особого в производительности не предвидится?

посоветовать более конректно, из-за скудности информации, я не могу

То есть выигрыша особого в производительности не предвидится?

а в чем охото получить прирост?

В скорости доступа к информации о размерах, расположении об определенной комнате, зная, какая комната с какой связана -> её индекс

по теории прирост получите

хотя >10000 комнат - это квадрат 100 на 100

Ключевое слово 'больше'

Планируется максимум 2 миллиона у.е. в ширину. Средний размер комнаты ≈20 у.е. в ширину

ну я к тому, что это не много данных, но в базе это скорее всего будет прирост по многим поисковым запросам, нежели тягать из файла, хотя с другой стороны, надо смотреть на объем данных, а то может там данных, которые поместятся в 1гиг озу и проще работать с памятью

Спасибо за информацию, буду дальше смотреть.

Планируется максимум 2 миллиона у.е. в ширину. Средний размер комнаты ≈20 у.е. в ширину

берите базу

берите базу

Прям точно?

?

ну как бы 2 ляма ширина, неизвестная высота, предполагаю квадрат, а это уже большие объемы

вам же скорее всего надо не просто количество комнат посчитать, а скорее иметь представление, что именно в таком-то квадрате

тут почти, как с гео координатами