Страницы: 1
RSS
Какую базу данных сейчас перспективнее изучать новичку
 
Добрый день
Посоветуйте, пож, новичку Базу Данных с точки зрения затраченные усилия по изучению / функционал БД
Порылся в интернете, вроде как лучше Access (интеграция с Ексель + VBA), но его не развивают, он устарел (интерфейс только красивее от версии к версии)... пишут что с каждым годом все сложнее получить помощь по изучению Access - т.к. все меньше людей им занимается... нет сайтов профессиональных (как Планета Ексель, например). Отставание от других БД функционально увеличивается.  И изменений вроде не предвидится, т.к. MS развивает другой продукт MS SQL Express. Есть конечно и фанаты свои, но такое сложилось ощущение - может ложное, что это больше люди которые когда то изучили, им хватает и другого они не знают... И все это с каждым годом по нарастающей.  
 
Цитата
Ливиан: Базу Данных
как по мне, это SQL по-определению. А вот Рассуждений на тему, какую базу данных (SQL) выбирать — полно))
Изменено: Jack Famous - 10.04.2019 08:44:54
Во всех делах очень полезно периодически ставить знак вопроса к тому, что вы с давних пор считали не требующим доказательств (Бертран Рассел) ►Благодарности сюда◄
 
Цитата
Ливиан написал:
Какую базу данных сейчас перспективнее изучать новичку
Российской разработка :-)
Access - можно изучать с точки зрения оболочки, в которой можно делать интерфейс, а вот где держать базу  - это отдельный вопрос, но как уже отмечено- тупиковая ветка.
По вопросам из тем форума, личку не читаю.
 
Для новичка посоветую Огнептицу (FireBird). По следующим соображениям: Она бесплатная. В ней есть практически всё, что может потребоваться для работы. Для работы с ней существует непревзойдённая по удобству оболочка IBExpert, которая, кстати, тоже бесплатная для пользователей с русской локалью.
Ну а в остальном выбор дело религиозное.
 
Цитата
Мартын написал:
, в которой можно делать интерфейс, а вот где держать базу  - это отдельный вопрос, но как уже отмечено- тупиковая ветка.
Цель изучения какая? ИМХО, в корпоративной среде MS SQL или Oracle. SQL запросы везде +\- одинаковые. Для изучения,я бы скачал MS SQL Express и их же учебную базу Northwind
 
Цитата
БМВ написал:
Access - можно изучать с точки зрения оболочки, в которой можно делать интерфейс, а вот где держать базу  - это отдельный вопрос,
да мне всё равно кажется, что всё упирается в RAM и в количество записей результатов запросов, нужных... и частоту их исполнения... - что и даёт комфорт работы с бд, т.е. эффективность скорости и памяти конкретно под задачу...
я вот не думаю, что если MS SQL Server Express оперирует 10гб памяти, а у меня только 2, - что мне будет хорошо... даже не знаю, при переходе на него, как мне  его заполнять - наверно явно не полностью, для комфортной работы...
хотя погоняла запросы на сервере (того что колупаю в Access) - то, конечно, скорость на порядок выше...
ох не знаю что выбрать - для здоровья своего и базы данных...
p.s.
а про интерфейс в цитате интересно сказано - действительно, можно ведь результаты стягивать Формой в Access (или сразу в .txt если надо) серверным движком,  проводя запросы к серверу, только всё равно не знаю, когда у меня лимит сервера в 10 гб закончится, на моих 2х гб RAM'a...?.. чтоб не получилось в самый неподходящий момент  :oops:  (когда делаю аналитику за приличный период)  8-0  
Изменено: JeyCi - 05.05.2019 18:40:51
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
MS SQL Server Express оперирует 10гб памяти, а у меня только 2
Вы не путаете понятия? 10 ГБ - это ограничение на размер файла базы данных в бесплатной (Express). Сервер не помещает всю базу в память.
Скорость работы (чтения) сильно зависит от качества индексов.
 
Цитата
pharmaprofi написал:
10 ГБ - это ограничение на размер файла базы данных в бесплатной (Express). Сервер не помещает всю базу в память.
просто когда он выполняет запрос - если запрос для расчётов аггрегирования по всей бд - то изначально ему надо взять в RAM всю базу  - насколько понимаю... а потом ещё нужна свободная память для этих действий по аггрегированию... или не правильно понимаю?..
например, использую конструкцию WITH X AS (тоже какая-нибудь промежуточная select'a) etc - он результат этого WITH изначально скидывает в отдельный пулл памяти, к которому потом и обращается далее по запросу... - а ведь это может быть намного больше, чем мои 2гб RAM - когда я обсчитываю все данные за раз...
Цитата
pharmaprofi написал:Скорость работы (чтения)
(но для чтения тоже ведь нужен кусок свободной ram)
хм, хотя если его работа (запроса) состоит в чтении, а этот отдельный пулл для результатов WITH - это часть hdd (что маловероятно), а не в RAM находится -- то вы развеете мои сомнения и опасения... а то неприятно будет провести кучу предварительной работы по миграции на сервер - чтобы потом встретиться с ограничениями RAM и необходимостью переходить на 64x систему и update'ить hardware ??...
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
JeyCi,
Цитата
JeyCi написал:
RAM всю базу  - насколько понимаю.
Это не так, да и для аналитики предназначен другой инструмент, OLAP. Что касается памяти и x64 системы, то x86 отпадет само, ибо стоимость памяти ничтожно мала, а вот разработчикам вести два потока разработки и поддержки - мало радости. MS уже отказалось давно от x86 серверных платформах. А вот что касаемо вашего железа, то почему нужно его модернизировать? Если у вас система x86 и менее 4Г памяти, что возможно, но маловероятно, а если 4, то ставьте x64 смело, конечно если процессор совсем не обрезанный. А добавить 2-4гб - гроши в сравнении с выигрышем.
По вопросам из тем форума, личку не читаю.
 
Цитата
pharmaprofi написал:
Скорость работы (чтения) сильно зависит от качества индексов.
"качество" - это в смысле их уникальности? и редкости появления их новых значений по Field'у?..
то  что индексировать по столбцам объединения JOIN и фильтрации WHERE - это всё что помню...
p.s.
и пояснения по предыдущему посту:
БМВ, разрабатываю я сама для себя (не для сети) - поэтому если кому и понадобится 64x, то только если сама на него перейду...
Цитата
БМВ написал: и менее 4Г памяти, что возможно, но маловероятно,
и тем не менее - факт...
дело не в стоимости ram, а в последующей потребности многое на vba потом переводить на 64x рельсы
- т.е. загвоздка комплексная...
Цитата
БМВ написал: MS уже отказалось давно от x86 серверных платформах.
но вроде ещё 2012 и 2014 install у меня где-то валяется... точно были 86x...
а OLAP из Access - тоже наверно скорости не прибавит сильно... имхо, вижу так
Изменено: JeyCi - 06.05.2019 10:06:15
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
объединения JOIN и фильтрации WHERE - это всё что помню..
Глобально да, но инструмент "анализ запросов" иногда предлагает свои оптимальные вариант индексов и статистик.  Я к тому, что скорость работы, на большой базе, скорее зависит от индексов чем от железа.

>а OLAP из Access - OLAP отдельная технология.  "Философия OLAP"-  все вычисления и агрегации сделаны в процессе подготовки куба. Запросы отрабатывают быстро.
Проблема в том, что у Miscrosoft OLAP (SSAS) не включен в Express. Если база для себя и локально - можно поставить SLQ для разработчиков. =
 
Цитата
pharmaprofi написал: инструмент "анализ запросов" иногда предлагает свои оптимальные вариант индексов и статистик.
кстати далеко не все из них, действительно, помогают...
Цитата
pharmaprofi написал: SSAS
вот спасибо ! - теперь знаю, чего мне не хватало...
Цитата
pharmaprofi написал: можно поставить SLQ для разработчиков. =
что за зверь ?? можел линк есть ?
p.s.
Цитата
скорость работы, на большой базе, скорее зависит от индексов чем от железа.
всё-таки повторюсь - и от количества получаемых данных в результате этого запроса... имхо...
а вот суть работы конструкции WITH x AS(...) - по скидыванию в отдельный пулл памяти для дальнейшего обращения к нему - всё-таки будет урезать RAM - даже при 4гб - если в запросе участвует база на 10гб... если кто сталкивался с поведением компа в такой ситуации - предупредите please - наверно, ведь, как обычно при нехватке ram, - всё вырубается, и гаснет монитор, (я такое обычно реанимирую на материнской плате, сбрасывая напряжение)  8)  
Изменено: JeyCi - 08.05.2019 06:30:00
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
что за зверь ?? можел линк есть ?
скачайте бесплатный специализированный выпуск
 
Андрей VG, спасибо за зверя...
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
суть работы конструкции WITH x AS(...) - по скидыванию в отдельный пулл памяти для дальнейшего обращения к нему - всё-таки будет урезать RAM - даже при 4гб
я, наверно, всё-таки !! поняла про этот отдельный пулл памяти - он ведь может быть и на Сервере !!! тогда ram остаётся не тронутой, и БД читается, как написал pharmaprofi, а не сканируется ram... а мне всё было интересно где этот пулл памяти?.. и чего им так пугают?
p.s.
это только LocalDB имеете технологию подключения к серверу (а отсюда и проблему) - "memory-share" - вот это, действительно, неприятная вещь...
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
по поводу железа, в том числе:
встретилась статья на хабре - и где-то среди её комментов такое
Цитата
скорость работы сервака можно тупо увеличить более мощным железом, которое нынче копейки стоит, то скорость передачи от нас мало зависит
Это как?
в связи с этим пару вопросов всё-таки остаются:
1) может количество ядер процессора или его мощь в Ггц всё-таки значимы - и насколько?.. и что лучше: 1 мощное ядро ИЛИ 2 ядра с такой же суммарной мощностью - при сравнении?
2) серверный винчестер? хорошее ли ускорение даст?..
(в связи с этим, полагаю, облачные сервера Azure как раз дают место НА серверных винтах, при том что вопрос скорости передачи данных - всё равно будет зависеть от i'net провайдера... имхо)
И ещё пару в связи со статьёй:
3) например Oracle, который разрабатывается под Linux и на Java (насколько понимаю)... (и в связи со статьёй) обязательно ли устанавливать его на виртуальном диске ИЛИ просто на винчестер лучше?..
и вопрос 4 (в котексте той статьи) -
4) так от чего же всё-таки зависит скорость - от компилятора?.. интерпретатора?.. процессора?.. или препроцессора?.. и у кого она быстрее - у MS SQL Server или у ние Oracle ?? ... [сравнение скорости компиляторов только для c++ ]
p.s.
думаю, такие вопросы для неспециалистов - очень нуждаются в ответах...  :( ... а то даже google мало понятно отвечает на них... если кто сможет объяснить на пальцах - заранее спасибо...  8)  
Изменено: JeyCi - 25.05.2019 12:27:09
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
>скорость передачи от нас мало зависит
думаю, что здесь речь об интернет канале.

>может количество ядер процессора или его мощь в Ггц всё-таки значимы - и насколько?.
все относительно, если речь не идет о корпорациях и реальной BigData - железо не так значимо.

Из опыта, в конфигурации Windows Server (на виртуалке)+ MS SQL, SSD дает заметный прирост скорости на операциях записи.

>... а то даже google мало понятно отвечает на них...
Несколько лет работаю с базами MS SQL и даже не задавался большей частью ваших вопросов. решайте проблемы по мере поступления - есть проблемы нагрузкой процессора - добавьте ядра. Памяти мало - увеличите. Благо, что на VDS это можно сделать в 2 клика, и за небольшие деньги.

>так от чего же всё-таки зависит скорость
-это вообще вещь относительная. Буквально на днях столкнулся с тем, что удалось увеличить скорость запроса с 35 до 10 секунд немного поменяв процедуру.
Процедура получала параметр, который у меня был прописан как nvarchar(256), при этом, приложение (EntityFramework) формировало запрос, где переменная передается как nvarchar(4000). Изначально, все работало нормально. Когда кол-во строк приблизилось к 5 млн., время выполнения запроса начало напрягать. Поменяв в процедуре  nvarchar(256) на  nvarchar(max) удалось его значительно ускорить. Что при этом происходит на сервере, и по какой причине такая разница из за небольших изменений синтаксиса - для меня загадка.

p/s на истину не претендую, скорее личные наблюдения.
 
1) все зависит от того, как используются эти ядра системой. Да и не получитсся получить описанное .
2) серверный винчетер может иметь другой интерфейс и другую частоту вращения диска, естетсвенно SAS и 15к лучше , но все это проиграет SSD, но облачные провайдеры предоставляют виртуальные ресурсы и размещены они на мощных СХД которые дают производительность такую, которую ни один HDD не даст. А в промежутке у них еще и кэш на SSD может быть , так что  …...
3) просто на винчестер будет хуже если виртуальный сделан на быстром СХД и наоборот.
4)- конкретно сравнить опыта не было.
По вопросам из тем форума, личку не читаю.
 
Цитата
pharmaprofi написал: решайте проблемы по мере поступления - есть проблемы нагрузкой процессора - добавьте ядра. Памяти мало - увеличите

в том то и вопрос, как узнавать с чем проблемы (чтобы по ходу править)... или профайлер сообщает об этом?

Цитата
pharmaprofi написал: Из опыта

спасибо, как раз такое и хотелось услышать

Цитата
pharmaprofi написал: даже не задавался большей частью ваших вопросов

про скорость работы компилятора возник вопрос исходя из выбора между ИЛИ Java для Oracle ИЛИ vb/c# для MS SQL ...

Цитата
БМВ написал: А в промежутке у них еще и кэш на SSD может быть , так что  …...

:)  так что - реально серьёзная вещь... думаю, в ситуации "читает" и "скидывает в отдельный пулл памяти результаты With" (о чём интересовалась ранее) -- может быть очень полезная вещь... думается мне... ведь кэш - тоже можно считать видом памяти (а я и не подумала ранее)
Спасибо !! за ответы (а то я плавала в этих нюансах)

Изменено: JeyCi - 14.05.2019 17:03:55
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
JeyCi, В данном случае это специализированный кэш для дисковых операций, который позволяет существенно ускорить работу с основным дисковым массивом, наращивая IOPSы . Простые расчеты производительности - ДИСКИ выдают от 70-150 IOPS в зависимости от скорости вращения. компактные быстрые диски пока сильно ограничены по объему, и для того чтоб получить объем нужно или очень много быстрых или в разы меньше медленных, но снижая количество шпинделей, существенно снижается суммарный IOPS, что можно компенсировать кэшем из дорогущих, но компактных и быстрых SSD.
По вопросам из тем форума, личку не читаю.
 
Цитата
JeyCi написал:
в том то и вопрос, как узнавать с чем проблемы (чтобы по ходу править)... или профайлер сообщает об этом?
В случае жалоб от пользователей\ тормозов - смотрю загрузку ОЗУ \ процессора. Если тормоза есть, а загрузки нет - значит проблема не с ними.
Профайлер вроде умеет отлавливать "долгие" запросы, но глубоко с ним не разбирался. В компаниях, где этот вопрос стоит остро - могут быть отдельные админы, которые отвечают за сервер баз данных и это их головная боль. На уровне когда сам себе админ - разобраться во всех тонкостях работы сервера будет не просто.

Если использовать вирутальный сервер - то там вообще темный лес. Может тормозить из за нагрузки \ атаки на соседние вируталки, о которых вы только догадаетесь.
 
Цитата
БМВ написал: IOPS
IOPS (аббревиатура от англ. input/output operations per second — количество операций ввода-вывода в секунду; произносится как «ай-опс») — количество операций ввода-вывода, выполняемых системой хранения данных, за одну секунду. - на хабре
Цитата
БМВ написал:
компактные быстрые диски пока сильно ограничены по объему, и для того чтоб получить объем нужно или очень много быстрых или в разы меньше медленных
да, тут уж придётся задумываться о Распределённой Базе Данных и новая головная боль (как дать возможность юзеру работать с ней так же, как с одной бд, и в плане скорости и в плане комфорта и в плане доступа к данным)... вобщем всё зависит от нужного объёма... Thanks
Цитата
pharmaprofi написал:
Если использовать вирутальный сервер - то там вообще темный лес.
:)  мне тоже так показалось... VDS, вами упомянутый выше, - Virtual Dedicated Server
всем ! Спасибо, за новые слова для понимания "как сделать выбор сервера и бд осознанно"
Изменено: JeyCi - 15.05.2019 10:52:29
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
да, тут уж придётся задумываться о Распределённой Базе Данных и новая головная боль
ни в коем случае. Все эти многочисленные физические диски собираются в рэйд массивы и видятся как единое пространство. Вот пример утилизации агрегатов на хранилище, самый большой еще разбит на тома, но это не важно, просто пример привожу

При этом решение дает как скорость, за счет распределения, так и отказоустойчивость. Но это не должно волновать админа БД или разработчика. Они должны определить IOPS и Latency при проектировании, а инфраструктурщики уже все настроить. Другое дело, что размер базы может достичь тех размеров, что движок будет не справляться.
По вопросам из тем форума, личку не читаю.
 
Цитата
БМВ написал:
физические диски собираются в рэйд массивы и видятся как единое пространство.
а это - действительно, хорошая новость !
Цитата
БМВ написал:
При этом решение дает как скорость, за счет распределения, так и отказоустойчивость.
это радует ещё больше... кстати, может в данном случае речь идёт о Многопоточности??..
просто, честно говоря, бд всё разрастается и разрастается... и даже в архив не сбросить, когда хочется посмотреть за весь период (значит, может всё-таки наступить критический момент - просто пока то, что смотрю, ещЁ и масштабировать хочется на др. активы - вот и интересуюсь, где во всей этой истории я встречусь с лимитом)... наверно, действительно, стоит погуглить возможности построения распределённой бд
Цитата
БМВ написал:
Другое дело, что размер базы может достичь тех размеров, что движок будет не справляться.
ну, тут уж думаю в помощь - VIEWхи, чтоб уж частями рассматривать бд - или при большом размере бд уже ничего не поможет ? (когда наткнёмся на ограничения драйвера)
Цитата
БМВ написал:
определить IOPS и Latency
БМВ  спасибо - уже смотрю:
What is Latency? And How is it Different from IOPS?
Understanding IOPS, Latency and Storage Performance
а здесь про всё - и про hdd, ssd, RAID и про Виртуальные решения (в конце - тонко подмечено)
p.s.
всё-таки это всё дело скорее для OLTP ... а если не так много транзакций, - скорее Data Warehouse DB более подходит... кстати пока мы обсудили тех. вопросы, мне кажется, я поняла, - Oracle и приложения для него на Java - видимо, больше для OLTP БД подходят... а MS SQL Server  (или его for Development Edition) и, наверно, приложения для него на vb/c# - для Data Warehouse DB... хотя Oracle и Data Warehouse DB предлагает, наверно и MS SQL Server и OLTP тоже реализовывает... вобщем на любителя того языка, на котором планируется писать приложение для взаимодействия с бд
Изменено: JeyCi - 16.05.2019 09:27:45
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
VIEWхи, чтоб уж частями рассматривать бд
и опять не про то. Размер может вырасти до такой степени, что регламентные задания, по перестройке индексов, сжатию …. будут занимать больше допустимого времени. В момент пересчета индексов - работы базы замедляется в разы, что со стороны клиента выглядит как неработоспособность,, при этом без пересчета база может и вовсе перестать нормально реагировать. Естественно я говорю о больших объемах и нагруженных решениях.
По вопросам из тем форума, личку не читаю.
 
Цитата
БМВ написал: и опять не про то.
да БМВ, перечитала ваш пост - вы о движке, а я о драйвере вспомнила - вообще о разном  :oops:
Цитата
БМВ написал: В момент пересчета индексов - работы базы замедляется в разы, что со стороны клиента выглядит как неработоспособность
вот почему "качество" индексов, упомянутое ранее - имеет оборотную сторону медали: ускоряет выборки (SELECT), но может замедлять вставки данных (INSERT INTO)...
спасибо вам, что наводите резкость в моих пока ещё обрывочных знаниях (добываемых google'ом - очень фрагментированым становится понимание от него) ... после ваших объяснений - всё раскладывается по полкам
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
ВСЁ-ТАКИ один нюанс ещё может быть важен ?
и Вывод: например в моём случае (приложение для взаимодействия с бд) надо полагаться на:
1) скорость и способности движка (with x as всё-таки комфортно, как и хранимые процедуры)
2) правильную индексацию
3) и IOPS с Латентностью
(даже на хостинг не хотелось бы)
p.s.
4) а клиент - на любителя
p.s.
в связи с этим последний вопрос ??? , если можно:
если у меня ключи - составные из нескольких полей
- стоит ли мне всё-таки Generate_ID - чтобы потом индексировать по одному полю ??? - добавит ли мне это скорости ? (точнее базе данных)
Изменено: JeyCi - 27.05.2019 16:56:52
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: Generate_ID
совет, в принципе, такой
Цитата
JeyCi написал: добавит ли это скорости ?
... выполнению Select'ов... -  по тому же линку пишут
Цитата
практически поиск по дополнительному полю уникального ключа может быть быстрее
Изменено: JeyCi - 24.05.2019 07:36:37
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Спасибо большое за советы. Подумав, решил все таки попробовать Access, т.к. вряд ли потяну профессиональную БД, плюс наличие VBA. Но разочаровался в скорости работы... все очень, очень медленно. Решил, что от добра добра не ищут и лучше Excel ничего нет, для меня во всяком случае.
Страницы: 1
Наверх