Что должен знать и уметь администратор БД

Sandro>> 1) Гвозди микроскопом не забивают.
yacc> Вообще не понял.

Возможности SQL-базированных систем для платёжных избыточны примерно как 3d-принтер по сравнению с карандашом. Для рисования платёжки такие навороты не нужны, более того — вредны.

Sandro>> 2) Оставлять ключ от входной двери под ковриком тоже неправильно.
yacc> Надо закрыть вход в парадную

А ты в подъезде не один живёшь

yacc> По части 1) - вовсе не значит, что если БД - платная - то она супернавороченная.

Примеры?

yacc> И да - что там с отечественными?

Просьба раскрыть вопрос, а то я не понял.

Sandro> Возможности SQL-базированных систем для платёжных избыточны примерно как 3d-принтер по сравнению с карандашом.
Ок. И как данные хранить будем - как по старинке в dbf файлах?

Sandro> А ты в подъезде не один живёшь
Там все свои если речь идет о выделенном сегменте сети

yacc>> И да - что там с отечественными?
Sandro> Просьба раскрыть вопрос, а то я не понял.
С отечественными БД

Sandro>Примеры?
Тот же самый MySQL в платной редакции.

Sandro> И вот постоянно случаются двойные списания средств, или вообще списания в никуда, невозможно восстановить историю транзакций в случае чего и т.д. По-твоему, это нормально?

а это не проблема СУДБ, проблема не там , проблема вообще не в софте ПРОЦЕССИНГА картона,

проблема как обычно в мусоре на входе по тем или иным причинам

с.т.>> причём гусениц ещё нет
Sandro> Гусениц есть и применяются. И не на велосипеде, а на танке. В нормально спроектированных системах.

вот тут мы и переходим к главному - проблема в том что система в целом гетерогенная, заплаточная, разные банки, разные страны, ПМС у операторш, человеческий фактор, кардеры\хакеры... и тп и тд, не нужно её лечить там где она не болит, нужно от этого отталкиваться и выстраивать такую процедуру работы (и дизайн) что бы она нормально работа в том виде в котором она объективно может существовать

с.т.>> секьюрити через обскьюрити - это вообще не выход, проблема вообще не там
Sandro> Где я такое предлагал ??? Ты офигел, что ли ???

а в чём смысл писать свою новую СУДБ - что бы там не было старых закладок\багов, но были свои новые (софта без багов \ НДВ не бывает если мы о больших системах с большим количеством пользователей говорим).

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

и особенно не просто СУБД а изобретать свою, нереляционнную




вместо того что бы сделать нормально спроектированную систему - украду у тебя цитату )) в которой by design движек хранилища данных сам по себе лежит в глубине и роли не играет, ты предлагаешь на нём СОСРЕДОТОЧИТЬСЯ )) ну во всяком случае вот так это со стороны выглядит, может ты что-то другое имел ввиду?

Sandro>> Возможности SQL-базированных систем для платёжных избыточны примерно как 3d-принтер по сравнению с карандашом.
yacc> Ок. И как данные хранить будем - как по старинке в dbf файлах?

Нет, разумеется. В виде инкрементального списка транзакций. И ... а вот тут сам догадайся, что ещё надо.

Sandro>> Просьба раскрыть вопрос, а то я не понял.
yacc> С отечественными БД

Ты по-прежнему не желаешь понимать правильно заданный вопрос.

Sandro>>Примеры?
yacc> Тот же самый MySQL в платной редакции.

Ещё раз: нафига тут SQL? Давайте собаке на хвост навесим адмиралтейский якорь, чтобы на месте плавать умела? Ты же это предлагаешь?

Заниматься высоконадёжными БП доводилось? Так вот, там всё не так.

 

Sandro> Нет, разумеется. В виде инкрементального списка транзакций. И ... а вот тут сам догадайся, что ещё надо.
Не - ты не понял - на файловой системе в каком виде хранить?

Sandro> Ты по-прежнему не желаешь понимать правильно заданный вопрос.
поясни

Sandro> Ещё раз: нафига тут SQL?
См. вопрос выше.

yacc> Не - ты не понял - на файловой системе в каком виде хранить?

Блоками запросов на транзакцию, общей длительностью порядка 1 секунды на блок.

Sandro>> Ты по-прежнему не желаешь понимать правильно заданный вопрос.
yacc> поясни

Я не понимаю, что тут пояснять. Всё же ясно, как перпендикуляр. Нам надо хранить историю платежей. Всё. На кой пень тут SQL???

Sandro>> Ещё раз: нафига тут SQL?
yacc> См. вопрос выше.

DROP TABLE ACCOUNTS

Ты реально хочешь, чтобы это было возможно?

Sandro> Блоками запросов на транзакцию, общей длительностью порядка 1 секунды на блок.
Блоки запросов - в каком виде?

Sandro> Я не понимаю, что тут пояснять. Всё же ясно, как перпендикуляр. Нам надо хранить историю платежей.
Еще раз - в каком виде? Ясен пень что история должна храниться на жестком диске.

Sandro> DROP TABLE ACCOUNTS
Sandro> Ты реально хочешь, чтобы это было возможно?
Ты сначала сделай это. А заодно чтобы почистить все бэкапы.
А то я в пример другое приведу - rm -rf / - и?

Sandro>> Блоками запросов на транзакцию, общей длительностью порядка 1 секунды на блок.
yacc> Блоки запросов - в каком виде?

Тут всё написано: http://www.swift.com/resources/.../standards_inventory_of_messages.pdf

Читай.

Sandro> Читай.
С тем же успехом я могу показать форматы ARINC для аэронавигационной базы данных. Это - текстовый файл, где каждая строчка соответствует определенной информации - на это есть большой документ с кодами.
И?

Я помню, как сначала у нас процессинг делали по такому файлу - читали его несколько раз ( ну чтобы ОЗУ хватило ), потом трансформировали в карту.
... пока не догадались сделать базу на SQL ( каком-то простом типа Firebird ), затащить данные сначала туда, а потом обрабатывать. Время обработки в разы сократилось.

Ты так и не ответил в каком виде это хранить, особенно если потребуются отчеты - а они потребуются 100% . Я правильно понимаю что ты предлагаешь плоский двоичный/текстовый файл со списком сообщений по указанному формату ? И отчеты тоже по нему строить ?

Поздравляю с достижением: ты меня разозлил настолько, что без непечатных выражений отвечать крайне сложно. На АБазе это мало кому удавалось.

Превозмогши себя, попробую: в серверную фигачит молния, все диски сгорают. Что ты будешь делать с транзакциями ? Будешь турма сидеть?
Деньги-то делись в неизвестно куда, а это статья.

Sandro> Превозмогши себя, попробую: в серверную фигачит молния, все диски сгорают. Что ты будешь делать с транзакциями ? Будешь турма сидеть?
Турма сидеть будет архитектор, который придумал все в одном месте хранить и без такого рода защиты.

Но ты так и не ответил - где данные хранятся ?

Sandro> Поздравляю с достижением: ты меня разозлил настолько, что без непечатных выражений отвечать крайне сложно. На АБазе это мало кому удавалось.

Тоже попробую. Непонятно, чего ты именно к SQL взъелся? Ну, избыточен, допустим, по функциональности, но достаточен по возможности задачи. Т.е. если цена за избыточность не пугает, какие проблемы-то?
+ SQL:
1) отлаженный механизм хранения больших массивов данных,
2) с наличием опций уместного в таком деле секционирования,
3) с наличием всякого сервиса по администрированию, зеркалированию, восстановления и т.д.
4) со встроенными средствами для аналитики этих самых больших массивов данных;
0) есть куча исполнителей под рукой, которые умеют это сделать на РСУБД (той или иной), которые уже что-то подобное делали, кактусов сожрали и граблей перетоптали немало.
- SQL:
1) централизация обработки и хранения данных - херово масштабируется вширь;
2) супостатское почти всё;

Sandro> Превозмогши себя, попробую: в серверную фигачит молния, все диски сгорают. Что ты будешь делать с транзакциями ? Будешь турма сидеть?

Поставишь какой-нибудь физически удаленный стендбай и будешь при этом терять тот минимум элементарных транзакций, который все равно бы потерял хоть с NOSQL, хоть при специализированных свистоперделках.

HolyBoy> Например, почему используется Mysql , которую только по ошибке называют СУБД?
Наткнулся тут на бывшего коллегу. О MySQL у него так

и вот так