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

Перенос из темы «Visa и Master Card в России. Какое будущее?»
 
1 2 3

Sandro
AXT

инженер вольнодумец

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

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

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

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

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

Примеры?

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

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

yacc

старожил
★☆

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

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

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

Sandro>Примеры?
Тот же самый MySQL в платной редакции.
 42.0.2311.9042.0.2311.90
RU спокойный тип #02.05.2015 12:04  @Sandro#01.05.2015 23:21
+
-
edit
 

спокойный тип
Спокойный_Тип

старожил

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

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

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

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

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

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

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

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

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




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

Sandro
AXT

инженер вольнодумец

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

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

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

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

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

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

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

yacc

старожил
★☆

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

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

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

Sandro
AXT

инженер вольнодумец

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

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

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

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

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

DROP TABLE ACCOUNTS

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

yacc

старожил
★☆

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

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

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

Sandro
AXT

инженер вольнодумец

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

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

Читай.
 37.037.0

yacc

старожил
★☆

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

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

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

Sandro
AXT

инженер вольнодумец

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

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

yacc

старожил
★☆

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

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

16-й

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

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

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

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

yacc

старожил
★☆

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

и вот так

PostgreSQL vs MySQL

В преддверии своего доклада на конференции PGCONF.RUSSIA 2015 я поделюсь некоторыми наблюдениями о важных различиях между СУБД MySQL и PostgreSQL. Этот... // habrahabr.ru
 

:)
 
Последние действия над темой
1 2 3

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru