From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DNS_FROM_AHBL_RHSBL, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:To:From:Date; bh=l/S0qZkwg5hLD5PgdtUI49jx5FCT1p07OFbIiN/3lPc=; b=bsbQlmUsV+i5yoDTF/mR8DRHC9KTMV/nJM1S1WwpR0N6U+jepRLxszHcORFUGFa3UAIu5v8alwblSeKOIyAT5tO6e9hTBlJw7rUt4OW8t/tJtTvHsQZ94oe10zXFcyP2+0PTs7SSTi1sbj4+cMAz1SQVvNA/YQRDuRecMJyK6RM=; Date: Wed, 21 Jan 2015 11:19:41 +0300 From: BatraevEM To: sarlug@lists.lug.ru Message-ID: <20150121111941.00003193@mail.ru> In-Reply-To: <54BF2F44.9030503@gmx.com> References: <54BE71D9.5040308@gmx.com> <54BF2F44.9030503@gmx.com> X-Mailer: Claws Mail 3.9.3-30-gd68093 (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-Spam: Not detected X-Mras: Ok Subject: Re: [Sarlug] =?koi8-r?b?UG9zdGdyZVNRTDog09DJ08vJINPT2czPyyDOwSDQz8zF?= =?koi8-r?b?IMTS1cfPyiDUwcLMycPZ?= X-BeenThere: sarlug@lists.lug.ru X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Saratov Linux User Group Maillist List-Id: Saratov Linux User Group Maillist List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 08:19:54 -0000 Archived-At: List-Archive: Доброго... Мне кажется слишком усложняешь для уровня SQL. если бизнес логику будешь делать на sql лучше делать так table elements table documents - потом проще будет логику на sql делать, и переносимость будет выше. например: CREATE TABLE tntp ( id serial NOT NULL, name character varying(128) NOT NULL, CONSTRAINT tntp_pkey PRIMARY KEY (id) ) CREATE TABLE tntp_tp ( id serial NOT NULL, tntp_id integer NOT NULL, ttp_id integer NOT NULL, CONSTRAINT tntp_tp_pkey PRIMARY KEY (id), CONSTRAINT tntp_tp_tntp_id_fkey FOREIGN KEY (tntp_id) REFERENCES tntp (id) MATCH SIMPLE, CONSTRAINT tntp_tp_ttp_id_fkey FOREIGN KEY (ttp_id) REFERENCES ttp (id) MATCH SIMPLE, CONSTRAINT tntp_tp_tntp_id_key UNIQUE (tntp_id, ttp_id) ) CREATE TABLE ttp ( id serial NOT NULL, name character varying(128) NOT NULL, code character varying(20) NOT NULL, CONSTRAINT ttp_pkey PRIMARY KEY (id) ) здесь промежуточная таблица tntp_tp для связи многие ко многим tntp и ttp. Если бизнес логика будет в отдельной программе то, скорее всего, действитьлно лучше смотреть в сторону nosql и acid делать на уровне программы. например mongodb очень архитектурно красив в плане обработки документов. например документ в монгодб: { "_id" : ObjectId("529c826c222115c5c72e57cc"), "handlers" : [ { "args" : { "ext" : 120, "jn" : 5, "oids" : [ "sysDescr", "sysUpTime", "sysName", "sysContact", "sysLocation", "sysObjectID" ] }, "func" : "snmp_poll" }, { "func" : "update_objects" } ], "ldt" : ISODate("2015-01-21T11:12:00.000Z"), "name" : "System", "period" : "5m", "status" : "on" } по любым полям можно делать индексы, вообще все очень быстро, но связывание документов и полей вообще никакое, поэтому в каждом документе нужно/лучше/быстрее хранить все. Если бы я сейчас начинал некоторые свои проекты с нуля поигрался бы с json в postgresql. Нужно еще учесть объемы и нагрузку, возможно, если нужна высокая скорость при больших нагрузках, то стоит забить на какие-то пункты из acid. Если же к системе будет 5-10 обращений в минуту и плевать что ответ формируется за 0.1-0.6 секунду (то есть не нужна обязательно 0.001 секунда), то сделай как можно проще для sql - самый первый вариант. У мну есть хернюшка которую я делал вообще на django с его самым медленным orm, но работает без особых проблем на базе в 5 Гб - к нему редко обращаются и ответ моментально не требуется... Вообще нужно учитывать, что все что заложешь сейчас в основание потом будет приследовать всю жизнь. Гарантированно через время (весьма короткое) эксплуатации в боевом режиме вылезут проблемы/доработки/красивости/удобства которые сейчас предусмотреть очень трудно - поэтому все используемые технологии должны давать возможность легкой модификации, причем желательно без кардинальной переработки. Тут конечно большой плюс у носиквела без схем данных. С другой стороны и постгресе можно сделать универсальную таблицу в ней почти все хранить, например: id bigserial NOT NULL, key text, type text, val text, cdt timestamp without time zone, rem text В Wed, 21 Jan 2015 08:47:00 +0400 NIR пишет: > Друг рассказывал. Также рассказал, что там нет системы транзакций. Я > посчитал, что в моём случае это станет критичным. > > 21.01.2015 08:53, Eugene Horohorin пишет: > про no-SQL знаешь? > > 2015-01-20 20:12 GMT+03:00 Dmitry Agafonov : > > Лично я бы рекомендовал не думать на уровне SQL, а думать на уровне > пользовательского интерфейса своей системы. > Обычно его делают на неких фреймворках, где есть связки с базой и > часто в составе есть (можно подобрать) ORM для отображения база > данных <=> программные объекты. > Исходить надо из того, какая структура нужна/генерируется для этого > ORM. > > В противном случае можно получить "ну не сложно же было сделать" > нечто, что будет очень сложно дебажить, расширять и дорабатывать. > > Также сразу надо иметь в виду возможные (вероятность 100% по опыту ;) > ) миграции структуры базы и данных. В некоторых ORM оно есть в > каком-то виде. > > > 20 января 2015 г., 18:18 пользователь NIR написал: > > Всем привет. > > С невеликим успехом пытаюсь писать ERP-PLM-PDM систему для завода. > Поставил PostgreSQL и начал думать над структурой БД. > > Дано: > - Список документов. Для простоты представим, что в системе все > документы представлены таблицей document с полями id (primary key), > uri и name. > > - Список элементов, представленный таблицей elements с полями id > (primary key), name и documents[]. Это может быть какая-то деталь, > например, кронштейн. К данной детали необходимо привязать список > документов (чертёж, спецификация, стандарт на крутящие моменты, > качество ЛКП и прочего). Я пытаюсь сделать это через хранение массива > documents[] типа bigint с id документов. Планирую разворачивать этот > список в программе в имена документов. > > - Структура элементов, представляющая собой таблицу mbom с полями id > (primary key) и structure. Поле structure имеет тип ltree > (используется модуль ltree из PostgreSQL) и в качестве элементов > дерева используются id таблицы elements. Эти id также планирую > разворачивать в программе в имена(дерево) элементов, образующие > крупные узлы продукции (локомотив). > > Вопрос: > Основной вопрос формулируется как: А правильно ли я вообще это сделал? > Может, есть способ получше? > 1) Можно ли SQL запросом обратиться к массиву documents[] таблицы > elements и по указанным там номерам раскрыть список документов? Не > хочу писать логику разбора массива в программе. > 2) Можно ли обратиться к полю structure таблицы mbom и по номерам > ракрыть список соответствующих элементов? Мотивировано тем же самым > нежеланием писать логику в программе. Хочу просто список из таблицы > elements. > > В SQL соображаю на уровне CREATE TABLE/ INSERT INTO. > > P. S.: Для работы используется Pgtcl из собственно интерпретатора Tcl. > P. P. S.: Могу попробовать нарисовать диаграмму того, что хочу > получить. > > -- > С уважением, Игорь Чудов > Энгельсский Инструментальный Завод "ЭИЗ" > Сайт: http://nir.org.ru/ > Телефон: +7 937 266-51-34 > > > _______________________________________________ > Sarlug mailing list > Sarlug@lists.lug.ru > https://lists.lug.ru/mailman/listinfo/sarlug > > > > > -- > Dmitry Agafonov ~ http://agafonov.pp.ru/ > > _______________________________________________ > Sarlug mailing list > Sarlug@lists.lug.ru > https://lists.lug.ru/mailman/listinfo/sarlug > > > > > > > _______________________________________________ > Sarlug mailing list > Sarlug@lists.lug.ru > https://lists.lug.ru/mailman/listinfo/sarlug >