Re: [Sarlug] PostgreSQL: списки ссылок на поле другой таблицы

Re: [Sarlug] PostgreSQL: списки ссылок на поле другой таблицы

[BatraevEM]

Доброго...

Мне кажется слишком усложняешь для уровня SQL.

если бизнес логику будешь делать на sql лучше делать так
table elements <many-to-many over table> 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 <faust@gmx.com> пишет:

> Друг рассказывал. Также рассказал, что там нет системы транзакций. Я
> посчитал, что в моём случае это станет критичным.
> 
> 21.01.2015 08:53, Eugene Horohorin пишет:
> про no-SQL знаешь?
> 
> 2015-01-20 20:12 GMT+03:00 Dmitry Agafonov <agafonovdmitry@gmail.com>:
> 
> Лично я бы рекомендовал не думать на уровне SQL, а думать на уровне
> пользовательского интерфейса своей системы.
> Обычно его делают на неких фреймворках, где есть связки с базой и
> часто в составе есть (можно подобрать) ORM для отображения база
> данных <=> программные объекты.
> Исходить надо из того, какая структура нужна/генерируется для этого
> ORM.
> 
> В противном случае можно получить "ну не сложно же было сделать"
> нечто, что будет очень сложно дебажить, расширять и дорабатывать.
> 
> Также сразу надо иметь в виду возможные (вероятность 100% по опыту ;)
> ) миграции структуры базы и данных. В некоторых ORM оно есть в
> каком-то виде.
> 
> 
> 20 января 2015 г., 18:18 пользователь NIR <faust@gmx.com> написал:
> 
>  Всем привет.
> 
> С невеликим успехом пытаюсь писать 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
>