blocks|key|3358435|text|考虑将数据放在Properties对象中并使用其load()/store()序列化。这是一种基于文本的技术，因此它在数据库中仍然是可读的：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3358436|public+String+getFieldsAsString()+{
++Properties+data+=+new+Properties();
++data.setProperty(+"foo",+this.getFoo()+);
++data.setProperty(+"bar",+this.getBar()+);
++...
++ByteArrayOutputStream+out+=+new+ByteArrayOutputStream();
++data.store(+out,+""+);
++return+new+String(+out.toByteArray(),+"8859-1"+);+++//store()+always+uses+this+encoding
}|code-block|syntax|javascript|3358437|要从字符串加载，请使用新的Properties对象执行类似的操作并load()数据。|3358438|这比Java序列化更好，因为它非常可读和紧凑。|3358439|如果您需要支持不同的数据类型(即不仅仅是字符串)，请使用BeanUtils将每个字段转换为字符串表示形式，或者将其转换为字符串表示形式。|3358440|entityMap|0|LINK|mutability|MUTABLE|url|http://commons.apache.org/beanutils/^0|7|A|O|E|0|0|D|A|X|6|0|0|S|9|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]|$9|11|A|12|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|13|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|14|8|@$9|15|A|16|B|C]|$9|17|A|18|B|C]]|D|@]|E|$]]|$1|M|3|N|5|6|7|19|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|1A|8|@]|D|@$9|1B|A|1C|1|1D]]|E|$]]|$1|Q|3|-4|5|6|7|1E|8|@]|D|@]|E|$]]]|R|$S|$5|T|U|V|E|$W|X]]]]

Consider putting the data in a <code>Properties</code> object and use its <code>load()/store()</code> serialization. That's a text-based technique so it's still readable in the database:

<pre><code>public String getFieldsAsString() {
 Properties data = new Properties();
 data.setProperty( "foo", this.getFoo() );
 data.setProperty( "bar", this.getBar() );
 ...
 ByteArrayOutputStream out = new ByteArrayOutputStream();
 data.store( out, "" );
 return new String( out.toByteArray(), "8859-1" ); //store() always uses this encoding
}
</code></pre>

To load from string, do similar using a new <code>Properties</code> object and <code>load()</code> the data.

This is better than Java serialization because it's very readable and compact.

If you need support for different data types (i.e. not just String), use <a href="http://commons.apache.org/beanutils/" rel="nofollow noreferrer">BeanUtils</a> to convert each field to and from a string representation.

blocks|key|3145782|text|我想说，如果POJO由字符串和原始类型组成，那么您的初始方法并不是那么糟糕。您可以强制对分隔符进行转义，以防止损坏。此外，如果您使用Hibernate，则需要将序列化封装在custom+type中。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3145783|如果您不介意其他依赖项，那么Hessian被认为是序列化Java对象的一种更有效的方法。|3145784|entityMap|0|LINK|mutability|MUTABLE|url|http://www.hibernate.org/hib_docs/v3/reference/en-US/html/mapping-types.html#mapping-types-custom|1|http://hessian.caucho.com/^0|2E|B|0|0|E|7|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

I'd say your initial approach is not all that bad if your POJO consists of Strings and primitive types. You could enforce escaping of the delimiter to prevent corruptions. Also if you use Hibernate you encapsulate the serialization in a <a href="http://www.hibernate.org/hib_docs/v3/reference/en-US/html/mapping-types.html#mapping-types-custom" rel="nofollow noreferrer">custom type</a>. 

If you do not mind another dependency, <a href="http://hessian.caucho.com/" rel="nofollow noreferrer">Hessian</a> is supposedly a more efficient way of serializing Java objects.

blocks|key|3145786|text|XStream、YAML或OGNL作为简单的序列化技术出现在人们的脑海中。XML是最常见的，但OGNL以最少的元数据提供了最大的灵活性。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3145787|entityMap|0|LINK|mutability|MUTABLE|url|http://xstream.codehaus.org/|1|http://jyaml.sourceforge.net/|2|http://www.ognl.org/^0|0|7|0|8|4|1|D|4|2|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]|$A|T|B|U|1|V]|$A|W|B|X|1|Y]]|C|$]]|$1|D|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]|N|$5|G|H|I|C|$J|O]]]]

<a href="http://xstream.codehaus.org/" rel="nofollow noreferrer">XStream</a> or <a href="http://jyaml.sourceforge.net/" rel="nofollow noreferrer">YAML</a> or <a href="http://www.ognl.org/" rel="nofollow noreferrer">OGNL</a> come to mind as easy serialization techniques. XML has been the most common, but OGNL provides the most flexibility with the least amount of metadata.

blocks|key|3358509|text|你可以通过外部化你的对象来优化序列化。这将使您完全控制它是如何序列化的，并提高流程的性能。这很容易做到，只要你的POJO是简单的(即不引用其他对象)，否则你很容易破坏序列化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3358510|tutorial+here|offset|length|3358511|编辑:这并不意味着这是首选的方法，但是如果ti是性能关键型的，并且您只能使用表中的字符串列，那么您的选择就非常有限。|3358512|entityMap|0|LINK|mutability|MUTABLE|url|http://www.codeguru.com/java/tij/tij0116.shtml^0|0|0|D|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

You can optimize the serialization by externalizing your object. That will give you complete control over how it is serialized and improve the performance of process. This is simple to do, as long as your POJO is simple (i.e. doesn't have references to other objects), otherwise you can easily break serialization.

<a href="http://www.codeguru.com/java/tij/tij0116.shtml" rel="nofollow noreferrer">tutorial here</a>

EDIT: Not implying this is the preferred approach, but you are very limited in your options if ti is performance critical and you can only use a string column in the table.

blocks|key|3145805|text|埃利奥特·鲁斯蒂·哈罗德写了一个nice+argument，反对对他的XOM库中的对象使用Java对象序列化。同样的原则也适用于你。内置的Java序列化是特定于Java的、脆弱且缓慢的，因此最好避免使用。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3145806|在使用基于字符串的格式方面，您大致有了正确的想法。正如您所说的，问题在于您遇到了分隔符的格式/语法问题。解决方案是使用已构建的格式来处理此问题。如果这是一种标准化的格式，那么您还可以使用其他库/语言来操作它。此外，基于字符串的格式意味着您希望通过观察数据就能理解它；二进制格式消除了这一选项。|3145807|XML和JSON是这里的两个很好的选择；它们是标准化的、基于文本的、灵活的、可读的，并且有很多库支持。它们的性能也会出人意料地好(有时甚至比Java序列化还要快)。|3145808|entityMap|0|LINK|mutability|MUTABLE|url|http://xom.nu/designprinciples.xhtml#d0e323^0|G|D|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

Elliot Rusty Harold wrote up a <a href="http://xom.nu/designprinciples.xhtml#d0e323" rel="noreferrer">nice argument</a> against using Java Object serialization for the objects in his XOM library. The same principles apply to you. The built-in Java serialization is Java-specific, fragile, and slow, and so is best avoided.

You have roughly the right idea in using a String-based format. The problem, as you state, is that you're running into formatting/syntax problems with delimiters. The solution is to use a format that is already built to handle this. If this is a standardized format, then you can also potentially use other libraries/languages to manipulate it. Also, a string-based format means that you have a hope of understanding it just by eyeballing the data; binary formats remove that option.

XML and JSON are two great options here; they're standardized, text-based, flexible, readable, and have lots of library support. They'll also perform surprisingly well (sometimes even faster than Java serialization).

blocks|key|3358622|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3358623|我有一个POJO需要在数据库上持久化，当前的设计将它的字段指定为单个字符串列，并且不能向表中添加额外的字段。|blockquote|3358624|3358625|3358626|你能创建一个新的表并在该列中放入一个外键吗！？！？:)我想不能，但让我们涵盖所有的基础！|3358627|Serialization:我们最近讨论过这个问题，所以如果我们的应用程序崩溃了，我们可以让它恢复到和以前一样的状态。我们本质上是将一个持久化事件分派到一个队列上，然后这个队列抓取对象，锁定它，然后序列化它。这看起来很快。你序列化了多少数据？你能让任何变量成为临时变量(即缓存的变量)吗？你能考虑拆分你的序列化吗？注意:如果你的对象改变(锁定)或者类改变(不同的序列化id)会发生什么？您需要将序列化的所有内容升级到最新的类。也许你只需要把它保存一夜，所以这并不重要？|offset|length|style|BOLD|3358628|xstream+XML：您可以使用像这样的东西来实现这一点。建立一些定制的东西是可行的(一个很好的面试问题！)，但我可能不会自己做。为什么要麻烦呢？请记住，如果您有循环链接，或者如果您多次引用对象。重新构建对象并不是那么简单。|3358629|数据库存储：如果您使用Oracle10g存储blob，请升级到最新版本，因为c/blob性能大大提高了。如果我们讨论的是大量数据，那么是否可以压缩输出流？|3358630|这是一个实时应用程序，还是会有一两秒钟的暂停，这样你就可以安全地持久化实际的对象？如果你有时间，你可以克隆它，然后在另一个线程上持久化克隆。坚持到底是为了什么？它是在事务内完成的吗？|3358631|entityMap^0|0|0|0|0|0|0|E|0|I|2N|0|0|25|0|0|2J|0^^$0|@$1|2|3|-4|4|5|6|V|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|W|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|X|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|Y|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|Z|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|10|7|@$J|11|K|12|L|M]]|8|@]|9|$]]|$1|N|3|O|4|5|6|13|7|@$J|14|K|15|L|M]]|8|@]|9|$]]|$1|P|3|Q|4|5|6|16|7|@$J|17|K|18|L|M]]|8|@]|9|$]]|$1|R|3|S|4|5|6|19|7|@$J|1A|K|1B|L|M]]|8|@]|9|$]]|$1|T|3|-4|4|5|6|1C|7|@]|8|@]|9|$]]]|U|$]]

<blockquote>
 I have a certain POJO which needs to be persisted on a database, current design specifies its field as a single string column, and adding additional fields to the table is not an option.
</blockquote>

Could you create a new table and put a foreign key into that column!?!? :)
I suspect not, but let's cover all the bases!

Serialization:
We've recently had this discussion so that if our application crashes we can resurrect it in the same state as previously. We essentially dispatch a persistance event onto a queue, and then this grabs the object, locks it, and then serializes it. This seems pretty quick. How much data are you serializing? Can you make any variables transient (i.e. cached variables)? Can you consider splitting up your serialization?
Beware: what happens if your objects change (locking) or classes change (diferent serialization id)? You'll need to upgrade everything that's serialized to latest classes. Perhaps you only need to store this overnight so it doesn't matter?

XML:
You could use something like xstream to achieve this. Building something custom is doable (a nice interview question!), but I'd probably not do it myself. Why bother? Remember if you have cyclic links or if you have referencs to objects more than once. Rebuilding the objects isn't quite so trivial.

Database storage:
If you're using Oracle 10g to store blobs, upgrade to the latest version, since c/blob performance is massively increased. If we're talking large amounts of data, then perhaps zip the output stream? 

Is this a realtime app, or will there be a second or two pauses where you can safely persist the actual object? If you've got time, then you could clone it and then persist the clone on another thread. What's the persistance for? Is it critical it's done inside a transaction?

blocks|key|3145899|text|考虑更改您的模式。即使您找到了一种将POJO序列化为字符串的快速方法，如何处理不同的版本？如何从X->Y迁移数据库？还是来自A->D的更糟？我看到了一些问题，我们将序列化对象存储到BLOB字段中，并且必须跨多个版本迁移客户。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3145900|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Consider changing your schema. Even if you find a quick way to serialize a POJO to a string how do you handle different versions? How do you migrate the database from X->Y? Or worse from A->D? I am seeing issues where we stored a serialize object into a BLOB field and have to migrate a customer across multiple versions.

blocks|key|361698|text|您需要在您的解决方案中考虑版本控制。数据不兼容是您在任何涉及使用对象的二进制序列化的解决方案中都会遇到的问题。如何将较旧的数据行加载到较新版本的对象中？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361699|因此，上面涉及序列化到名称/值对的解决方案可能是您想要使用的方法。|361700|一种解决方案是将版本号作为字段值之一。当添加、修改或删除新字段时，可以修改版本。|361701|反序列化数据时，可以为每个版本使用不同的反序列化处理程序，这些处理程序可用于将数据从一个版本转换为另一个版本。|361702|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

You need to consider versioning in your solution. Data incompatibility is a problem you will experience with any solution that involves the use of a binary serialization of the Object. How do you load an older row of data into a newer version of the object?

So, the solutions above which involve serializing to a name/value pairs is the approach you probably want to use. 

One solution is to include a version number as one of field values. As new fields are added, modified or removed then the version can be modified.

When deserializing the data, you can have different deserialization handlers for each version which can be used to convert data from one version to another.

blocks|key|361710|text|标准的JavaBeans持久化机制怎么样：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361711|java.beans.XMLEncoder
java.beans.XMLDecoder|code-block|syntax|javascript|361712|它们能够从XML+(已经持久化到XML)创建Java+POJO。根据记忆，它看起来像是……|361713|<object+class="java.util.HashMap">
++++<void+method="put">
++++++++<string>Hello</string>
++++++++<float>1</float>
++++</void>
</object>|361714|您必须提供PersistenceDelegate类，以便它知道如何持久化用户定义的类。假设您不删除任何公共方法，那么它对模式更改是有弹性的。|offset|length|style|CODE|361715|entityMap^0|0|0|0|0|5|J|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|W|8|@$M|X|N|Y|O|P]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

How about the standard JavaBeans persistence mechanism:

<pre><code>java.beans.XMLEncoder
java.beans.XMLDecoder
</code></pre>

These are able to create Java POJOs from XML (which have been persisted to XML). From memory, it looks (something) like...

<pre><code>&lt;object class="java.util.HashMap"&gt;
 &lt;void method="put"&gt;
 &lt;string&gt;Hello&lt;/string&gt;
 &lt;float&gt;1&lt;/float&gt;
 &lt;/void&gt;
&lt;/object&gt;
</code></pre>

You have to provide <code>PersistenceDelegate</code> classes so that it knows how to persist user-defined classes. Assuming you don't remove any public methods, it is resilient to schema changes.

blocks|key|3145946|text|你可以试试Protocol+Buffers，它是谷歌的一个开源项目，据说速度很快(比XML生成更短的序列化形式，而且运行速度更快)。它还轻轻地处理新字段的添加(插入默认值)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3145947|entityMap|0|LINK|mutability|MUTABLE|url|http://code.google.com/p/protobuf/^0|5|G|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You might try <a href="http://code.google.com/p/protobuf/" rel="noreferrer">Protocol Buffers</a>, it is a open-source project from Google, it is said to be fast (generates shorter serialized form than XML, and works faster). It also handles addition of new field gently (inserts default values).

blocks|key|358353|text|你调查过JAXB吗？它是一种机制，通过它可以定义从XML+Schema创建的一套java对象。它允许您从对象层次结构编组到XML，或者将XML解组回对象层次结构。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|358354|entityMap|0|LINK|mutability|MUTABLE|url|http://jaxb.java.net/^0|4|4|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Have you looked into <a href="http://jaxb.java.net/" rel="nofollow noreferrer">JAXB</a>? It is a mechanism by which you can define a suite of java objects that are created from an XML Schema. It allows you to marshal from an object hierarchy to XML or unmarshal the XML back into an object hierarchy.

blocks|key|361724|text|我的第二个建议是使用JAXB，或者可能使用XStream+(前者更快，后者更关注对象序列化部分)。此外，我还将进一步推荐一个不错的基于JSON的替代方案，Jackson+(http://jackson.codehaus.org/Tutorial)，它可以将bean完全序列化/反序列化为JSON文本以存储在列中。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|361725|哦，我绝对同意，在任何情况下都不要使用Java二进制序列化来进行长期数据存储。协议缓冲区也是如此；两者都太脆弱，不能用于此目的(它们更适合于在紧密耦合的系统之间传输数据)。|361726|entityMap|0|LINK|mutability|MUTABLE|url|http://jackson.codehaus.org/Tutorial^0|2E|10|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

I'll second suggestion to use JAXB, or possibly XStream (former is faster, latter has more focus on object serialization part).
Plus, I'll further suggest a decent JSON-based alternative, Jackson (<a href="http://jackson.codehaus.org/Tutorial" rel="nofollow noreferrer">http://jackson.codehaus.org/Tutorial</a>), which can fully serializer/deserialize beans to JSON text to store in the column.

Oh and I absolutely agree in that do not use Java binary serialization under any circumstances for long-term data storage. Same goes for Protocol Buffers; both are too fragile for this purpose (they are better for data transfer between tigtly coupled systems).

blocks|key|3145995|text|如果您使用分隔符，则可以使用您知道不会出现在文本中的字符，如\0或特殊符号http://unicode.org/charts/symbols.html|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3145996|但是，将数据发送到数据库并将其持久化所花费的时间可能比序列化的开销大得多。因此，我建议从一些简单易读的东西(如XStream)开始，看看你的应用程序在哪里花费了大部分时间，并对其进行优化。|3145997|entityMap|0|LINK|mutability|MUTABLE|url|http://unicode.org/charts/symbols.html^0|11|12|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

If you are using a delimiter you could use a character which you know would never occur in your text such as \0, or special symbols <a href="http://unicode.org/charts/symbols.html" rel="nofollow noreferrer">http://unicode.org/charts/symbols.html</a>

However the time spent sending the data to the database and persisting it is likely to be much larger than the cost of serialization. So I would suggest starting with some thing simple and easy to read (like XStream) and look at where your application is spending most of its time and optimise that.

blocks|key|359203|text|你可以试试Preon。Preon的目标是成为二进制编码数据，就像Hibernate对于关系数据库和JAXB对于XML一样。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|359204|entityMap|0|LINK|mutability|MUTABLE|url|http://preon.flotsam.nl/^0|5|5|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You might try <a href="http://preon.flotsam.nl/" rel="nofollow noreferrer">Preon</a>. Preon aims to be to binary encoded data what Hibernate is to relational databases and JAXB to XML.

I have a certain POJO which needs to be persisted on a database, current design specifies its field as a single string column, and adding additional fields to the table is not an option.

Meaning, the objects need to be serialized in some way. So just for the basic implementation I went and designed my own serialized form of the object which meant concatenating all it's fields into one nice string, separated by a delimiter I chose. But this is rather ugly, and can cause problems, say if one of the fields contains my delimiter.

So I tried basic Java serialization, but from a basic test I conducted, this somehow becomes a very costly operation (building a ByteArrayOutputStream, an ObjectOutputStream, and so on, same for the deserialization).

So what are my options? What is the preferred way for serializing objects to go on a database?

Edit: this is going to be a very common operation in my project, so overhead must be kept to a minimum, and performance is crucial. Also, third-party solutions are nice, but irrelevant (and usually generate overhead which I am trying to avoid)

Homemade vs. Java Serialization

对象存储

数据存储

数据库

JSON

Java

我有一个POJO需要在数据库上持久化，当前的设计将它的字段指定为单个字符串列，并且不能向表中添加额外的字段。这意味着，对象需要以某种方式序列化。所以为了基本的实现，我设计了我自己的对象的序列化形式，这意味着将它的所有字段连接成一个漂亮的字符串，由我选择的分隔符分隔。但是这是相当丑陋的，并且可能会引起问题，比如如果其中一...

问自制与Java序列化
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问自制与Java序列化EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问自制与Java序列化
EN