Відкат змін до БД
Доброго дня. Підкажіть як відкотити зміни в таблиці БД після того, як відпрацьовано Post. Правильність заповнення основної таблиці БД перевіряється за допомогою SQL запитів, прописаних в окремій таблиці. Але щоб запит відпрацював необхідно, щоб дані були занесені в основну таблицю, тобто. метод Post відпрацював. Але якщо виявлена помилка в заповненні, необхідно відкотити зміни. Як це зробити?
задіяти механізм транзакцій використовуваної БД. Хоча, підозрюю, тут архітектуру докладання лагодити треба.
←→Олександр_2012 ( 2014-03-21 15:14 ) [2]
Є низка правил заповнення основний таблиці, причому можуть змінюватися, тому перевірка правильності винесено на окрему таблицю. Тому просто не уявляю, як змінити програму. А як задіюється механізм транзакцій? Можна приклад чи посилання?
> [2] Александр_2012 (21.03.14 15:14) > А як задіюється механізм транзакцій? А БД яка скажеш нарешті?
←→Олександр_2012 ( 2014-03-24 09:25 ) [4]
> [4] Александр_2012 (24.03.14 09:25)Який тоді ще метод Post, якщо є спеціальна мова - SQL називається, в ньому багато чого є взагалі, а вже в Ораклі і ще більше. А зокрема, все це робиться в рамках транзакцій. Не треба користуватися будь-якими TTable.
> за допомогою SQL-запитів, прописаних в окремій таблиціце як?
←→Олександр_2012 ( 2014-03-24 10:40 ) [7]
> Запити типу: select Count(*) from table1 where pole1=1 > and pole2<>5а чому б не робити ці перевірки до внесення даних?
←→Олександр_2012 ( 2014-03-24 10:50 ) [9]
> Змінив OraQuery наOraTableОсь він чарівний метод.> Та й на SQL метод Post ніхто не скасовував.Чого-чого?> які оператор набрав у DBEdit-ах,Ось їх і треба викинути насамперед. Є процедури, що зберігаються, пакети. Читай про них. А перевірка лабуди, яку хочуть внести до БД, має бути до внесення. Нема чого всяке сміття туди тягнути.
←→Олександр_2012 ( 2014-03-24 11:16 ) [11]
> Та й на SQL метод Post ніхто не скасовував.
Неточно висловився, хотів сказати у компонентів, які працюють із SQL, тобто. OraQuery.
> які оператор набрав у DBEdit-ах,
Ось їх і треба викинути насамперед.
Тобто. я правильно зрозумів, що замість DBEdit краще використовувати Edit та програмно обробляти?
> замість DBEdit краще використовувати Edit та програмно обробляти?ну це вже від конкретного завдання залежить. Іноді краще. Але і з DB-версіями можна робити валідацію. Н-р, TField.OnSetText, OnValidate
> Тобто. я правильно зрозумів, що замість DBEdit краще використовувати > Edit і програмно обробляти?Не важливо, звідки братиметься ін-фа. По-хорошому (правильному) delphi-прогер не повинен замислюватися про структуру БД. У БД повинен бути реалізований інтерфейс для додавання певної кінцевої сутності (документ, проводка, списання зі складу і т.п.) у вигляді процедури, що зберігається.
Дані перевірив, передав у зберігання, отримав результат.
> По-хорошому (правильному) delphi-прогер не повинен замислюватися > про структуру БДЦе якщо delphi-прогеру пощастило, і в конторі є спеціально виділений db-прогер. Але так далеко не завжди і не скрізь
←→Олександр_2012 ( 2014-03-24 11:28 ) [15]
У мене на кількохвкладках візуалізується близько сотні полів БД. Якщо використовувати Edit, то при прогортанні БД доведеться написати досить великий фрагмент коду, який оновлюватиме інформацію у всіх Edit-ах.
>TField.OnSetText, OnValidate Дякую, подумаю, як це можна використовувати для вирішення задачі.
> Це якщо delphi-прогеру пощастило, і в конторі є > спеціально виділений db-прогер. Але так не завжди > і не скрізьА тоді й нема чого на Оракуль дивитися :)
> У мене на кількох вкладках візуалізується близько сотні > полів БД. Якщо використовувати Edit, то під час прогортання БД > доведеться написати досить великий фрагмент коду, який > оновлюватиме інформацію у всіх Edit-ах.
І кому потрібна така візуалізація? Інформація повинна відображатися, коли необхідна, а не щоб було.
GUI - переробити; DB-архітектуру - швидше за все теж.
А що заважає вставляти дані у ХП? Там же й усі перевірки реалізувати
> Там же і всі перевірки реалізуватиНе завжди можна (зручно) перевірки в ХП робити, Наприклад валідність ІПН. Та й не БД-шне це діло архітектури, а не контенту
> якщо pole1=1, то pole2 має дорівнювати лише 5такі перевірки краще робити на клієнті. з видачею відповідної лайки при фелі, або обмеженням у самому контролі
Та й так, не річ писати сміття в базу заради його перевірки, навіть якщо і транзакцію постійно відкочувати.
> хоча з тим же ІПН перевірку на сервері зробити не важко.Та ну нафіг, там же розряд ключується.
> Та ну нафіг, там розряд ключується.+ і потім, церобота GUI, користувач повинен бачити що вводить.
←→Олександр_2012 ( 2014-03-24 15:14 ) [25]
Саме потрібні всі поля для візуалізації. Скажімо докладну інформацію про об'єкт.
>А тоді й нема чого на Оракуль дивитися :)
Без вибору БД генерувалась не мною, змінити в основних таблицях нічого не можу, а користуватися треба і для операторів створити зручний інструмент.
>А що заважає вставляти дані в ХП? Там же й усі перевірки реалізувати
Оператор, вводячи значення в комірки цілком може помилитися, як і людина, який надав інформацію, тому за збереження (в ідеалі) проводиться перевірка з усіх існуючих взаємозв'язків і за виявленні помилки чи помилок запис БД повинна блокуватися з виведенням повідомлень про помилки.
Ну і так, не діло писати сміття в базу для його перевірки, навіть якщо і транзакцію постійно відкочувати.
Я це розумію, але не можу придумати іншого способу реалізувати численні перевірки (на сьогоднішній день близько 60), причому умови та кількість перевірок у нас можуть змінюватися 1-2 рази на рік. Тобто. потрібна можливість легко змінювати умови перевірки. А писати аналізатор рядкових виразів – це дуже складно.
> аналізатор рядкових виразівякщо умови не сильно заплутані, то достатньо таблиці виду Field FieldValue DependentField DependentFieldMin DependentFieldMax ----------------- -------------------------------------------------- Pole1 1 Pole2 5 5 Pole1 1 Pole3 10 15 .
> Саме потрібні всі поля для візуалізації. Скажімо, докладна > інформація про объекте.Ось не треба тільки казки розповідати. Так прямо всі поля відразу всіх "об'єктів". Не вірю.
> Без вибору БДгенерувалася не мною, змінити основні > таблиці нічого не можу, а користуватися треба і для операторів > створити зручний інструмент.Так про вибір СУБД питання не стоїть, тільки програміста до неї в поставці немає
> Я це розумію, але не можу вигадати іншого способу реалізувати > множинні перевірки (нині близько 60), > причому умови та кількість перевірок у нас можуть змінюватись > 1-2 рази на рік. Тобто. потрібна можливість легко змінювати умови > перевірки. А писати аналізатор рядкових виразів – це > дуже складно.
А не треба вигадувати. Усі вже давно вигадали і навіть розповіли.
А якщо чесно, то підручник з PL-SQL у зуби і гризти, гризти, гризти. починаючи з основ: SELECT, INSERT, DELETE, JOIN, .
> причому умови та кількість перевірок у нас можуть змінюватись > 1-2 рази на рік. Тобто. потрібна можливість легко змінювати умови > перевірки. А писати аналізатор рядкових виразів – це > дуже складно.Я цю логіку (того ж ІПН і ін.) давно в dll виніс,
←→Кщд (2014-03-24 19:19) [31]
>Олександр_2012 (24.03.14 15:14) [25] ОФОМС?
Перевірки валідності даних зазвичай реалізуються check-і referential intergity-констрейнтами та тригерами, що спрацьовують на додавання/зміну записів. Ці механізми слід вивчити документацію до використовуваної СУБД.
> Перевірки валідності даних зазвичай реалізуються check-і referential > intergity- констрейнтами та тригерами, що спрацьовують на > додавання/зміна записів. Ці механізми слід вивчити > з документації до використовуваної СУБД.:)))
> check-і referential intergity-констрейнтами і тригерамице вже останній рубіж, якщо користувачеві вдалося таки прорватися крізь решту клієнт-серверної валідації. а referential intergity - так це взагалі більше не до валідності, а до цілісності даних відноситься
> то це взагалі більше не до валідності, а до цілісності даних > відноситься
Хіба ці поняття чимось суттєво відрізняються з погляду прикладної галузі? На мій погляд – зовсім нічим.
> Ці механізми слід вивчити за документацією до > СУБД.Золоті слова. Відлити в золоті, під скло та на стіну. Автору - викинути GUI, гарненько стукнутися головою об стіну, щоб забути назавжди слова на кшталт DBEdit і т.п. НАЗАВЖДИ заборонити прямий доступ користувачів до таблиць, це має бути у крові. Будувати GUI треба так, ніби скористатися ним будуть диверсанти, які мріють зіпсувати БД. Добре познайомитися з ХП і тригерами, вони допоможуть вирішити твою проблему. І ще одне - нормальна людина може обробити мозком за раз не більше 17-20 "інформаційних об'єктів" і то це межа, а рівень комфортного сприйняття закінчується на 10 об'єктах, тому виводити на екран більше 10 рядків даних або більше 10 характеристик якогось об'єкта безглуздо , це сприймається. Потрібно групувати різні другорядні характеристики, прибирати їх з екрана і відображати лише за окремим натисканням кнопки "Докладніше".
> Треба групувати різні другорядні характеристикиPageControl керує
по сабжу - додати поле deleted вставляємо з ознакою Видалений, якщо коректно - прибираємо ознаку.