Есть желание перейти с FoxPro на сетевую СУБД. Какой язык программирования выбрать?

foxpro это еще свежачок. у нас была одна система емнип на клиппере с «сетевой базой» на шарах нетвари. переписал все на рельсы и постгрес.

не каких полумер

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

постгря как самая адекватная боль

в точку

python

а почему не MySQL?

inner join в ней сложный сделайте - поймете.

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

Язык из современных самый простой после фокса будет C#.

inner join в ней сложный сделайте - поймете.

делал. Брат жив )

типа тормозит она на них, это имелось в виду?

Вкури это: http://www.harbour-project.org/

ЗЫ Не пробовал, предпочёл Постгрю, Си, Пайтон

Ну так с одного узла читать, а на другой писать. Опять таки - про объем данных и нагрузку на БД в топике ни слова

Да очень много зависит от структуры данных, порядка полей в запросе, наличия индексов и кривизны рук кодеров и DBA

Хотя джойны в принципе тормозная хрень

ага... все на это ругаются

ну да. я работал только с базами более 10 Гб

с чего это join то тормозной? Смотря что на что джойнить

А еще как джойнить и какие индексы при этом юзать :) Я не использую джойны потому, что у меня базы в основном по шардам разложены и юзать джойны тупо не получится

какого же размера БД? Или данным мало связанны?

А я вот join очень много использую. Просто джоин обычно идет на таблицы, котоыре вообще в память влазят (около 100-1000 строк)

БД по-разному, бывает и гигов по 300-400. Это базы данных от сайтегов с большим трафиком. Шардинг реализован на уровне фреймворка, большие таблицы разбиваются тупо по id (только не «заполнили один сервер, перешли на следующий», а есть определенная логика для равномерного заполнения всех шардов)

А при большом трафике и малом времени актуальности данных, задержка в 15% запроса с джойном, например, против трех запросов, но с быстрой выборкой по индексу, бывает весьма и весьма и существенной

join то тоже индексы использует

а реализовывать join во framework't может быть просто ужасно.

Вообще постгря их хорошо кушает. Даже когда они с group идут

join то тоже индексы использует

Их сначала надо правильно расставить :)

инедексуем все :)

у нас сложно это сделать... не когда не знаешь, что в голову заказчика придет

а реализовывать join во framework't может быть просто ужасно.

Да не, по сути используется чистый sql, оптимизированы лишь рутинные операции, типа простых выборок по одному полю. Фреймворк необходим, потому что он знает на какой шард отправить запрос и снимает эту головную боль с разработчика. Если все лежит на одной машине, то никто не мешает написать запрос с джойном. А если его еще хорошенько прогнать через explain и грамотно оптимизировать, то все вообще отлично. Просто на это надо время и такая оптимизация проводится, как правило, только в том случае, если выясняется, что данный запрос - реально узкое место

Индекс на всех полях увеличивает объем базы и может, напротив, тормозить запросы. Рекомендую тщательно покурить mysqlperfomanceblog.com

У нас сейчас почти все запросы - узкое место. Хотя в самой боевой системе БД вообще не используется, ей хоть отвались вся база - она все равно работать будет.

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

это «штука» была

Может имеет смысл денормализовать данные и проставить более простые индексы? Можно существенно все ускорить

и так достаточно денормализованно. Далее денормализация приводит к росту базы, и к увеличению скорости чтения на проценты, но и время вставки увеличивается. там есть задатки кубов olap. данные при вставке сразу агрегируются в таблицы для многих типов отчетов. Но иногда им раз в месяц хочется чего нибудь эдакого.

Но иногда им раз в месяц хочется чего нибудь эдакого.

Ну это да, всегда самое узкое место - это кастомер =)

вот я сейчас думаю, как бы в базу вливать данные сразу в несколько поток. там много «update or insert» (чего в постгре нет, но сделал достаточно быстрое решение) и транзакции длиной по 3-4 минуты

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

ну да... тут шаманить надо... а постргря быстрее такой объем данных не кушает

clipper же. Программы на Clipper работают на Linux без помощи dosemu http://www.itk.ru/

http://sourceforge.net/projects/x-clip/

или http://www.harbour-project.org/

Был кроссплатформенный клон FoxPro на питоне, но я не помню названия, так что гугли.

Нашёл: http://dabodev.com/

Посмотри в сторону PostgreSQL + Tcl/Tk

Доступ к БД PostgreSQL из программ на Tcl/Tk:

• Quick-start guide to use of PostgreSQL with Tcl
  
• Устаревшая, но способная кое-что прояснить, статья на русском
  (стандартный Tcl уже содержит средства доступа к PostgreSQL искаропки)

Tcl, как встроенный в БД PostgreSQL язык:

• Exploring the postgres tcl environment
  
• PostgreSQL 9.0.6 Documentation Chapter 40. PL/Tcl - Tcl Procedural Language

Литература по Tcl/Tk:

• Tcl and the Tk Toolkit (pdf) (eng)
  
• Tcl/Tk . A Developer's Guide (pdf) (eng)
  
• Брент Уэлш, Кен Джонс «Практическое программирование на Tcl и Tk» (рус) Скачать книгу с сайта (23 Мб)
  

Графические элементы GUI, мягко говоря, выглядят не очень утончённо и современно, но если у вас получится подружиться с Tcl/Tk и PostgreSQL, то получите обалденный кроссплатформенный инструмент.

перейти с FoxPro

http://dabodev.com/